Hi Hilaire,
On 3 Mar 2018, at 15:21, Hilaire <hilaire@drgeo.eu> wrote:
Le 02/03/2018 à 22:52, Marcus Denker a écrit :
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed).
Situation improved :) Remember P3 was just above 20 MB
There are things to look for:
1) wasted space due to not thinking about memory and just âhaving itâ.
Of course some of it are things like duplications (we now have 2 browsers, 2 inspectors, 2 debuggers⦠time to clean up a bitâ¦).
Then every test we add takes space, every âhelp topicâ, every feature...
It looks like this topic comes and goes since 20 years: new features added, image growth then/or it becomes hard to unload ; on Squeak then now with Pharo at a much higher rate.
We all know about the right approach (GNU Smalltalk, CUIS Smalltalk), but it is not the road chosen with Pharo and it is becoming extremely uninteresting for me to code on DrGeo now. So far I fell ashame to ship end user application with a 50MB DrGeo image, knowing only 10% has purpose related to DrGeo domain. When situation improves, motivation may come back. For this same reason and other, I turned to Python for a planed programming course to mid high school students.
I think thatâs unfair. First, 38m is a really small application nowadays. I think for the amount of features included, 38m is a very small size (just look at any other application around⦠and of course scripting does not count by itself, it has to be added with all support files it come). Second, âthe right approachâ is always a matter of opinion. Of course, we believe *we* took the right path :) Third, yes, we added new functionality that could or could not be there (for example, I believe Athens should be a loadable project, not part of the image, but since everybody want to use it and even we were planning to move our tools to use, we included it). And yes, we have duplicated tools that we need to clean. But creating an environment that allow the development of any kind of application will always mean we increase the size of the release artefact. Finally fourth, we invested a LOT of effort on bootstrapping so you can do your image of the size you want. So yes, we deliver an image of 38m, and also a minimal image of 18m which you can use as base to create your production images. And if thatâs not enough, you can always do *your own*, since the scripts for doing it are available by just cloning the sources.
But of course sometimes being able to invest memory into a better system can be important, too. Not all growth in memory is negativ if you can afford it.
I always like to play the game to think âwhat would they have done in 1978 if they had this amount of memory in even a $5 machine?" Of course one can go very quickly in the wrong direction, but
Very likely not that much. May be the wonders came because of the hight constraints.
nevertheless: sometimes it is really worth to think about âspending memoryâ to buy abstraction. (especially a there are counter measures⦠we under-utilise both compression and disk storage) Helps could (should?) be file based, and maybe other stuff I don't know.
many things could be outside the image, yes. But then we need to distribute them. And that adds complexity.
How the image is considered in the Pharo team? A kind of sacred place, where stuff are added following a few guidelines (you will not duplicate features but replace/imprive/whatever -- aka funny shortcut mess, you will make your code unloadable, etc...) or just like a forum where teams add feature according to projects or vision.
We have a close control of what goes inside the image. And we take care things are well documented and with coherence of their components. Of course, we have made mistakes (maybe a lot), but in general things are improving. Esteban
Sorry to discuss these topics again, really don't want but still need to share a few thoughts.
2) wasted space that is just not needed. e.g. there is issue https://pharo.fogbugz.com/f/cases/21172/ That we have some huge strings to init unicode. Do we need them?
3) Memory leaks, bit they are more for the case when the system is running for a while.
-- Dr. Geo http://drgeo.eu