A possibility would be the AST cache. During development, if you do things like recompileAll or load packages the AST cache can grow the image size up to 300 Mo. But this cache is deleted when saving & quitting the image.

Did you save and quit the image before looking at the memory size ?

It might also be bugs related to Morph as you suggested because there was refactoring in it. We are investigating.

2013/7/29 Marcus Denker <marcus.denker@inria.fr>

On Jul 29, 2013, at 11:29 AM, phil@highoctane.be wrote:

> Hello,
>
> I've been loading all of those packages in order to build a full web stack development image.
>
> Everything now loads fine and kind of works but...
>
> The image is really slowing down and the size is getting very large.
>
> Here is the current one:
>
> �332580684 29 jul 10:50 Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image
>
> 300+ megs...
>

Can you try to execute

ImageCleaner cleanUpForRelease

This way we know if maybe some cache is hanging onto something.

> I've been doing some development in there and started looking for why this was getting so large and slow.
>
> I did a SpaceTally print analysis and imported the results in a spreadsheet.
>
> Look at the top consumers, especially the Semaphore thing. It is way beyond whatever was expected. There is something wrong there.
>
> There must be a leak of Points, MorphExtensions and I can't just figure out why there are so many Floats.
>

MorphExtension should only be referenced by the Morph it extends. So there should always be more Morphs than extensions.
This looks really strange.

� � � � Marcus