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