Performance Profiling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Performance Profiling

Casey Ransberger-2
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?
--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: Performance Profiling

hernanmd
2010/5/13 Casey Ransberger <[hidden email]>:

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

I think #storeString may fail when the receiver has recursive
references, that could be the case for Morphs when trying to store the
World morph (which contains your morph in the submorphs collection).

Hernán

Reply | Threaded
Open this post in threaded view
|

Re: Performance Profiling

Chris Muller-3
In reply to this post by Casey Ransberger-2
> 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?

I would say, that's a very good guess..  #storeOn: probably doesn't
truncate at appropriate points.

#storeOn: is a novel piece of Smalltalk nostalgia, but I have found
there to be very little practical use for it..  :(

> It would be funny if I was accidentally trying to store the
> whole world, as that seems both wacky and cyclic:)

It's a connected object.  I wouldn't be surprised if, somehow, the
Smalltalk and it's 'globals' dictionary was also being included in the
store string.  Wouldn't *that* be wacky on materialization..?  :)

> I'm not sure if it's even a bug, but it seems that I *should* be able to
> store morphs.

You probably can with simple SmartRefStream.  You definitely can with
Ma object serialization.

> Oh wow! I just noticed something else that's interesting: experimenting with
> this has rapidly obliterated the charge on my battery, too.

Right, 100% CPU.

> Does anyone have any pearls of wisdom that might help me understand better
> what's going on here?

It seems you did.  :)