Share via

Sparkle and Performance

  • Article

In my history of Sparkle I mentioned I had worked on ToolBook.  That solicited this comment:

Asymetrix's ToolBook? Wow, that was so ahead of its time! Just
make sure Sparkle runs faster! :P Sorry, could not resist. I am sure
Sparkle will rock.

We are currently in a performance milestone on Sparkle,
dealing with our obvious perf problems and reporting real and potential
Avalon perf problems to that team.  The good news is overall perf
is good.  Startup is fine, working set is fine, but as these
things go we have individual areas that don't scale well or just are
awful.  In Avalon you build your UI compositionally by creating
Templates that generate elements for the structure.  For example,
rather than a Button having a Render() method that draws a bunch of
rounded rectangles and text, you create a Template of primitive Shape
and Text Elements, include a layout container like a Grid or Canvas and
every time the system sees a Button it stamps out a copy of all those
elements.  Elements are not free however, and if you aren't
careful with your Templates they can explode into huge structures
without you noticing.  This is a working set hit and layout and
render takes longer.  We added commands to our diagnostic menu
that let us count the number of elements in different parts of the tree
and dump them for further study.  When we started perf work before
the PDC Sparkle would startup with over 8000 elements in its UI. 
Today that is down to 3000 with no difference in the look and
feel.  I expect this number to improve considerably this week and
more next as more changes come in.  We virtualized some things and
just got more careful in a bunch of places.

One of the worst offenders is not surprisingly our
Timeline, since it is such a complex piece of UI.  The Timeline
starts out with about 600 elements and then grows by 60-100 each time
the user adds a single element to the scene they are working on. 
Without virtualization this grows indefinitely.  I've seen the
Timeline with 50000 FrameworkElements in it (for comparison, imagine a
Win32 app with 50000 HDCs or HWNDs in it...not that that is
possible).  My colleague Kenny Young (visible in the Channel 9
vid, talking about Layout) is reducing the initial size of the
Timeline, and another couple of Sparklies have been working on
virtualization.  I'm expecting checkins this week that will
transform Timeline perf.

I came to work on ToolBook when it was already about 5
years old.  I had seen the product and, like the commenter,
thought it was ahead of its time, but terribly, just awfully, awfully
slow.  I quickly learned the backstory.  ToolBook had been
one of the first Win 3.0 apps, and had been written using a very
sophisticated object-oriented C metaphor.  Messages were passed
from place to place and there was a fancy interpreted OO language
(OpenScript) that ran much of the functionality.  I guess the
developers counted on machines getting faster and the functionality
just being so compelling that it would sell anyhow.  Instead they
got a PR nightmare.  Lots and lots of people saw the "DayBook"
demo that was included with Windows 3.0...found the product to be
unusably slow and never looked back.  The ToolBook team tore into
the codebase to optimize it.  They wrote a P-Code compiler for the
language (good idea), rewrote much of the OO C in assembly (made it
faster...but...uh...) and stripped a lot of the message passing
out in favor of shared global state (bad idea).  ToolBook 1.5 had
decent performance.  The next version (3.0 ... what happened to
2.0 is another story) was faster yet, but by then Visual Basic was
blowing ToolBook out of the mainstream RAD business and Director was
starting to push it aside in multimedia tools. 

Ironically, by the time I started the product was pretty
zippy.  Pentium processors ran all that hand-optimized assembly
awfully darn fast.  But it was way too late.  When I told
people I worked on ToolBook they'd usually say "Oh, I tried that. 
I remember it was really slow..."

I'm not going to repeat that.

Comments

  • Anonymous
    October 02, 2005
    John, all this made me blush a great deal, however I am happy my comment led you to speak about Sparkle’s performance characteristics. I am also glad you are making so much progress. I saw in the videos on Channel9, and I think Sparkle already looked VERY impressive before the PDC.

    Now, I have one concern: Not that we are all going to write such a complex UIs, but it appears that making a sophisticated Avalon application reach good performance takes much tuning.

    Now, I am a newbie, but I assume that by virtualization you mean that you create and dispose (perhaps reuse?) UI elements whenever they become visible or hidden.
    Wouldn’t it be nice that this kind of optimization were performed by Avalon itself? This could be especially useful, since I think there is a balance to be kept among working set (number of elements) and creation-destruction rate.

    And thanks for the inside story of ToolBook. I didn't use the product a lot, but I have a friend that did, and I always had a great respect for the technology.
  • Anonymous
    October 03, 2005
    The comment has been removed
  • Anonymous
    October 03, 2005
    John, thank you for addressing my concern and all the information. I hope we can experience a CTP soon. About VirtualizingStackPanel, thanks too. Sorry if it was a silly question, as I said, I am a complete Avalon newbie.