> On 2 Mar 2018, at 21:31, Hilaire <hila...@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 
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 
   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.


Reply via email to