[squeak-dev] Profiling .image space??

Jim Rosenberg jr at amanue.com
Mon Jan 28 01:39:15 UTC 2013


--On Sunday, January 27, 2013 19:03:44 -0500 "David T. Lewis" 
<lewis at mail.msen.com> wrote:

>> Squeak 4.3 won't load projects saved under 3.8 without conversion.
>> To  bypass having to learn how to do that, I've been "capturing" all the
>> objects for each 3.8 project as submorphs of a single morph, saving that
>> morph to file, and loading it into a new project in 4.3.

>> it is ballooning my .image size, and I would like to
>> try  to get a handle on this. Just porting a family of 12 projects is
>> giving me  an image size of 106M;

> Have a look at SpaceTally.

Thank you! This is giving me a good clue, but I don't know why what I'm 
seeing is happening. In my original development 3.8 image -- which contains 
lots of stuff not brought into the 4.3 image -- for class ByteArray I have 
this:

Class                           code space # instances  inst space percent
ByteArray                             3571        4839      16926101    15.3

and in the 4.3 image I have this:

ByteArray                             2591        6879      56548983    50.4

It sure looks to me like morph loading is eating up image space in 
instances of ByteArray that are not released after the morph has loaded.

For "my stuff", if you would ask me for an off-the-top-of-the-head idea 
where my "big ticket" image space usage would be I would have guessed 
Bitmap. Well, not so. In the 4.3 image Bitmap is only 4.3%!

The .morph files are pretty big -- around 4M - 5M per project. Before I 
burn lots of time digging into the code for morph loading, does any of this 
ring a bell with anybody?

-Thanks, Jim


More information about the Squeak-dev mailing list