Performance Profiling

> Today I was doing an impromptu demo of the Squeak system for a friend and
> former coworker. As is usually the case with demos, especially ones which
> aren't given much forethought, something went wrong.
> I thought he might be impressed to see me create a morph, drop it into a
> workspace, and then ask it for it's storeString, so I tried that. The image
> hanged as though grinding through something of massive computational
> expense. I didn't see anything about the polygon morph in question that
> would seem to be terribly expensive to serialize as code, and picked it
> because it was a relatively simple morph. Fortunately I was quite prepared
> for this to go wrong and set the stage accordingly (as the same thing
> happened when I tried using storeString to move the welcome screen text into
> the 4.0 images that I was making.)
> It feels like a performance problem, as though something here was winding up
> with a very, very big-O. I tried running the profiler and then reproducing
> the problem again, but I need to do cmd-. to get free of the hang, and after
> interrupting that way, moving the hand to the top of the screen does not
> cause the profiler results to appear, which is a big bummer.
> I'm stumped.
> When I interrupt the hang, I don't see a totally consistent stack, but I'm
> usually in the middle of a #storeOn:, which seems right, and one thing which
> struck me as odd was that I will occasionally interrupt and find myself
> inside of PasteUpMorph>>storeOn:. Maybe the system is trying to serialize
> the owner ivar? It would be funny if I was accidentally trying to store the
> whole world, as that seems both wacky and cyclic:)
> I'm not sure if it's even a bug, but it seems that I *should* be able to
> store morphs.
> Oh wow! I just noticed something else that's interesting: experimenting with
> this has rapidly obliterated the charge on my battery, too.
> Does anyone have any pearls of wisdom that might help me understand better
> what's going on here?