Prestashop 7 RC1 over 128MB...

[Radium]

Hi all, sorry if this has already been brought up, I tried searching and I was surprised to find there have not been any topics on this.

 

A wordpress + woocommerce install comes out at 28.8MB while prestashop is coming in at a whopping 128MB. Since we're already in release candidates stage I would think more optimizations should be in place before release... I would imagine it is a security risk waiting to happen with all that extra code floating around.

 

I'm just going to list the portions that are >1MB with >3MB in bold.

• vendor (69.5MB)
  • tecnickcom (28.8MB)
  • symphony (21.9MB)
  • phpoffice (7.1MB)
  • doctrine (4.3MB)
  • composer (1.7MB)
  • prestashop (1.0MB)
• admin (12.5MB)
  • themes
    • default
      • css (5.5MB)
      • template (1.4MB)
    • new-theme
      • public (1.8MB)
  • filemanager (1.6MB)
• translations (11.5MB)
• install (8.3MB)
• themes (6.7MB)
• js (3.8MB)
• classes (3.7MB)
• controllers (2.8MB)
• modules (2.3MB)
• app (2.2MB)
• tools (1.5MB)
• src (1.4MB)

Edited September 23, 2016 by Radium (see edit history)

[Apium]

But what, precisely, is your point? Storage space is cheap these days, and most of this footprint is not actually caused by the code, but rather by styling (e.g. that massive admin /css folder) and third-party apps.

 

In terms of footprint and folder size, most of it resides in /vendor. This is third-party code (including the new symfony framework!) used by PrestaShop, and not so much part of the native application. Maintenance of this code is largely done by these other projects themselves.

 

It's just a very rich platform, with many default themes (including for the backoffice) and options! The footprint on the filesystem is indicative of such.

Edited September 23, 2016 by Apium (see edit history)

[Radium]

My primary point is that unused code/files should be removed for both development efficiency as well as security (every unnecessary php file has the potential to introduce unintended security flaws).

 

Here are some reasons why unused code should be removed-:

• For anyone new working on a project, they not only have to understand the working code, they have to understand unused material also. This is wasted time and creates confusion.

• There is a danger that at sometime someone will make a change which inadvertently involve the 'dormant' code and can introduce bugs. I know it's happened on projects I've worked on.

• The maintenance of any code is an administrative burden. By preserving old redundant code that burden is increased. For example, merging changes in the main branch becomes harder because there is more code to work through and more possibility to make a mistake.

• What happens over time is that more and more old unused code is added to the codebase. This increases the confusion, potential misunderstanding and administrative overhead.

• The chances that the unused code will ever be used again is very unlikely. With time that possibility of re-use diminishes. If code to be removed and is considered important enough then the code can be branched off and documented.

• Any personal feelings that a coder may have about code they may have worked hard on are understandable. But part of being professional requires that those thoughts have to put to one side for the better good. Time stands for no-one and there is no place for preserving historical code in a working codebase.

[source http://stackoverflow.com/questions/15699995/why-unused-code-should-be-deleted]

[Traumflug]

But what, precisely, is your point?

 

It's simple: More code == more chances for bugs, lower performance. In addition to that all the maintenance and development costs Radium described.

 

That said, PS 1.7 started a foundation transition and because that's a whole lot of work, it can't be done all at once. At least not in back office. That's why there are currently two sets of frameworks, two translations systems, such stuff. Fortunately, PrestaShop developers do remove code no longer needed.

[Apium]

I do agree that unused code should be removed stat, and definitely not be present in a production version of the software. But do we know if this code is unused?

 

Personally, I think the transition onto Symfony is simply causing a lot of overhead, as Traumflug already described. Besides this, most of the files in /css, /themes, and /install are either styling (not so much executable code) or only there for the initial installation.

[Traumflug]

Styling is code, too, of course. It has to be downloaded, interpreted and applied.

[Krystian Podemski]

Did you noticed that most of this list is related to not compiled assets, and packages downloaded using Composer? Packages from composer aren't part of the "merging" process from branch to branch, not compiled assets should be delivered with the package. 

 

Maybe there is some unused code but not that much, really.

[Traumflug]

Let's pick up a few numbers. This is what currently makes up my shop:

.../www/html/shop$ du -sm .
1005    .
.../www/html/shop$ du -sm .git
263    .git
.../www/html/shop$ du -sm themes/classic/_dev
520    themes/classic/_dev
.../www/html/shop$ du -sm app/cache
40    app/cache

Code is organised in a Git repo, populated by distribution ZIPs. That's why one can subtract all the stuff in .git. Most of the stuff in themes/classic/_dev/ is node_modules/, gained after a 'npm install'.

 

Files I currently consider to be neccessary for just running the shop: 1005 - 263 - 520 - 40 = 182 megabytes. And there are fewer product pictures than the ones coming as demo.

 

Opinions on wether 182 MB are well manageable likely vary :-)

 

[Krystian Podemski]

"node_modules" is only on development, there's no "node_modules" on production, also - as you may know, there would be no ".git" or any other "dev" files in the package.

[Traumflug]

"node_modules" is only on development

 

That's why I substracted this amount from the total.

[Krystian Podemski]

I don't think that size is a problem, Magento is over 200mb and no one complains

[Radium]

I decided against using magento in any of my projects due to its slowness -- likely due to being unoptimized. I wonder how many others have?