On 2 Mar 2018, at 21:31, Hilaire <hilaire@drgeo.eu> wrote:

Ah, you are right it is a 32bits image.

My bad, Dr.Geo does not build with 64bits image Pharo7.0-64bit-52a28a8

ConfigurationOfDrGeo class methodsFor: 'metacelUnmatched ' in string literal. ->

May be should try a more recent P7 64 bits image


Note: 52 MB is an overlarge image size for me (down 50% will be nice)


we should again do some analysis where space is going��� the Pharo7 download
is now 38MB (the image, decompressed).

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... 

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
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)

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.

Marcus