Sparkle and Performance
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.