At 08:02 AM 7/7/01 -0400, Bob Arning wrote:
>Hi Ross,
>
>On Fri, 6 Jul 2001 23:16:33 -0700 Ross Boylan 
><RossBoylan at stanfordalumni.org> wrote:
> >Pretty cool.  It's very slow on my machine though (viewing my morph),
> >and it's a pretty fast one (700Mhz Athlon with Matrox Millenium G200
> >card).  However, the morph I made, which is essentially a giant table
> >made of rows made of cells, is suspiciously slow on its own.
> >
> >I just did my first profile; nothing glaring came out.  Given my
> >complete ignorance of Morphic performance issues, I may have done some
> >very unfortunate things.
>
>Why not send me the profile? I may be able to spot something.

Thanks; that's very generous.  How do I send it?  I can display the profile 
results, but see no obvious way to get them out of the system.  By the way, 
screen capture wouldn't work because the results are more than one screen 
(also I don't know how to do it).

I'll send the results off list as they are a bit bulky and probably not of 
general interest.

I can describe a few things I've done for which your response might be of 
interest.  Is there anything you can say about the following strategies' 
effect on performance?  (or there general wisdom?)

I built graphics out of morphs, rather than overriding the drawOn 
method.  So I get grid lines by putting line morphs in my morph, and by 
surrounding each cell with a bordered morph.  My guess is that is 
inefficient compared to modifying  drawOn.  The TableMorph I got 
(referenced on swiki page on GUI builders--can't remember who did it but AK 
is on the change stamps) uses a drawOn strategy.  I'm not using it anymore 
because I wanted different behavior.

There is a moderate amount of nesting.  For example, starting from an inner 
cell I have
UpdatingStringMorph < ActivityCellMorph < ActivityRow < ActivityTableMorph.

The table is large enough that some of it is typically off-screen.  Is 
there any special penalty there?

I override some of the event handling to capture clicks in the right place.