Profiling .image space??

I have some projects that I'm working on moving from Squeak 3.8 to Squeak
4.3. 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. This seems to work
fine. The 3.8 .morph files load into 4.3 with no "adventures", and things
work great in 4.3, identical behavior, no problems.

Except for this: 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; this is for an artistic work that was originally
realized in Hypercard and fit with room to spare on a 1.4M floppy disk! The
.image for just this one work is bigger than my development 3.8 .image that
has "everything", so something is getting exploded in size by saving a
morph under 3.8 and then loading it under 4.3.

Is there a way to profile an image to find out where all that disk space is
going?

Normally speaking, without knowing anything about how it works, I'm in
complete and total awe of the .image format; I am always totally astonished
-- each and every day, nearly -- at how fast image save is. Something has
to be built spectacularly right for images to be this efficient! It kind of
goes against the grain to have something to complain about regarding .image
...

On Sun, Jan 27, 2013 at 06:34:46PM -0500, Jim Rosenberg wrote:
Have a look at SpaceTally. The class comment gives some tips on how to use it.
I'm not sure what the problem is, but the SpaceTally took may help you to
find it.

It's nice to know that you are having success in moving your work from 3.8
to 4.3. People sometime question whether it is worthwhile to put effort into
backward compatibility - this is one of the reasons that it is important :-)

Dave

--On Sunday, January 27, 2013 19:03:44 -0500 "David T. Lewis"
<[hidden email]> 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

That amount seems like it might be the morph files themselves. Try something like

PointerFinder on: (ByteArray allInstances detect: [ :e | e size > 1000000]) "make number big enough to get one of the new guys"

Cheers,
Bob

--On Sunday, January 27, 2013 19:03:44 -0500 "David T. Lewis" [hidden email] 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

> It's nice to know that you are having success in moving your work from 3.8
> to 4.3. People sometime question whether it is worthwhile to put effort into
> backward compatibility - this is one of the reasons that it is important :-)

+1