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