Dashboard: a technical overview

We asked guiguiguillaume, member of our forums, to provide us with some information and reflexions about Dashboard. Here's his first draw, that shall probably be completed later on.

After your message, I went further into my researches on the issue of memory used by widgets. It's essentially questions I had about widgets, yet some researches made some other things appear.
About Dashboard being slow...
First of all, what I'm pointing here is not that the translator is slow (probably more because of the systran than the host machine), but that launching Dashboard is slow.
Basically I'm not the activity monitor fan, I mean, either my machine lags or not, whatever the figures...
In the present case, my personal selection of 8 widgets is often slow (on my G4 1.25, 512/80@4700tpm), that's why I went looking for what interesting things the figures had to say.
Not a big guess that the swap is responsible of the widgets slow appearance, and moreover, the slow mouse focus on them for interacting. A second consecutive launch of Dashboard will be immediate, while during the first one, the HDD would work until the system will let you grab hold at 100 % again.
Not very surprising when you see what RAM amount the widgets will request. Over time some will use 15 Mo... 8 times, you imagine what that makes. About it:
- I didn't quite get why the situation got worse over time, yet that's the case. The weather widget will use 5 Mo on launch, and will use 20 after 3 days...
- a portion of this RAM undoubtedly is shared (you can't just add rough values), thus artificially increasing the total amount, yet in what proportion it is hard to tell.
I first thought it was to much, and wondered if there weren't any grievous architecture misshapings. My first idea was that each Widget could duplicate some WebKit code in its RAM space... but this didn't make much sense (what's the point in having a "library" if you duplicate your code), and this just doesn't seem like it can be done.
I renounced the idea of a link between swap time and the power and speed of the WebKit, experimentaly. If it was rendering that took such machine time, it would have been possible to get more performance by making sure the different parts of the WebKit really were in RAM (not in SWAP), and that is easy to do, you just have to have Safari display some pages (I took care to get pages with some JS, png, gif... to be sure) before launching Dashboard. It won't seem to have much impact on Dashboard launching performances.
One step further was to monitor closely the request to virtual memory, more specifically OSX, to find out when it would go and seek memory parts in virtual RAM to put them in physical RAM. At least, I get a good measure of what RAM amount transits.
As expected, a direct call to Dashboard, if it was just launched, won't cause any pagein.
On the other hand, when saturating my physical RAM physique (by launching Garageband, 10 tracks; mail, adium, safari, iPhoto, GoLive, Word...) and call Dashboard again, I measured 6,000 to 8,000 page-ins with my 8 widgets. Without any widget, calling Dashboard alone would cause 100 to 200 page-ins ; Dashboard with the clock widget only about 500 pageins.
To compare, with a similarly saturated system, putting iPhoto to the forefront (edition of a picture mode) will cause about 2,800-3,000 page-ins.
Though those are fairly precise measures, you realise a loaded Dashboard will necessitate twice as much memory access than displaying an edition mode of iPhoto, which accounts for its slowliness.
You might explain dashboard slowliness by looking to its architecture as Apple described it: for stability reasons, the widgets are independent processes(you may cause a widget to fail, withtout the wholde widget collections to stall), each one related to its webkit for dispaly and JS interpretation purposes, but also more intricately related to the system (possibility to call the system, Obj-C particularly, via JS). Which can be even harder as the code can't be entirely compiled in the Widget, which will let the "runtime" some more job to do ("finishing the compilation" during execution).
To make Dashboard stable (RAM protection for the widgets) and allow easy programming (yet potentially as powerful as programming in Obj-C native), you have an architecture that gives each widget a consequent weight, in an independent process.
That's why launching Dashboard takes so long. It's the typical "10 small things will result in one huge" thing. Especially as those "small things" are called for simultaneously, thus resulting in much competition in the call of the system.
Can Apple increase performances? One can imagine they already thought of putting the Dashboard drawing in cache to allow a quick rendering of the "superposed" Finder, and from the architectural point of view (for what I could see), the choices made were quite good; even if one theoretically speculate on other execution modes (less protected), that would compile (on launch or installation) the active widget codes in a single execution context... well... at this level many hypotheses are possible.
The main problem in my view lies in RAM restitution of the n execution contexts for n proceses for their update on launching Dashboard.
And there there's no miracle, if those n processes are in swap, with so much competition, with a saturated system (physically recalling a page will put another in swap), it's long. Not often more than 10 seconds to get back 100% control, but it's like eternity...
More RAM to avoid that Dashboard is put in swap is still the best way to do. You might also recall Dashboard 3 times a minute to make sure it won't go in swap, yet this will be kind of annoying.