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.