[Chandler-dev] Chandler Performance: Who's doing what

[Bryan Stearns]

I'm setting aside the triage work until I can see what the perf tboxes 
say about my most-recent change; I'm going to spend a little time on 
figuring out why table scrolling is 4x slower on Windows than all the 
other platforms.

(good summary, Grant!)

...Bryan

Grant Baillie wrote:
> Here's a brief summary of what I think people are (and have been) up 
> to during the first few days of our performance tri-week (or 
> fortnight-and-a-half). Most of it is gathered from IRC, mailing lists, 
> and in-person conversations. Mostly, this email is so that everyone 
> has a vague idea of what everyone else is working on, so that work 
> doesn't get duplicated.
>
> * If I've omitted or misrepresented stuff you're working on, feel free 
> to send out corrections.
>
> * Also, if you have grand (but implementable :) performance ideas that 
> no-one is looking at, now would be a good time to suggest them.
>
> But first, some ...
>
> Successes
> ---------
>
> + Andi and Bryan came up with two groovy improvements in indexing 
> performance:
>
>      + When an item's position in a sorted index needs to be recalculated
>        (typically, because some attribute that contributes toward a
>        sorted index has changed), first check if it needs to be moved
>        at all by comparing it with its left and right neighbors.
>
>        It turns out this saves a lot of compare() calls when an item's
>        triage-related information changes, because triage attributes
>        are used in all the Dashboard's indexes, but only as a secondary
>        sort key (for breaking ties) in most of the columns.
>
>      + Allow for caching of attribute values in MethodIndex compare()
>        calls. This is a win because calculating an item's position in an
>        index takes O(log2(n)) compare calls, but the expensive part of 
> the
>        compare is looking up each of the two uuids's attribute values.
>        Since the same uuid will be an argument to compare() multiple 
> times,
>        it's a win to remember its values.
>
> + Heikki noticed a regression in "new" style sharing as compared to 
> what we had before, and he, Andi and Morgen tracked it down to a 
> change in the use of some repository API (mapHistory() vs 
> mapHistoryKeys())
>
> + John's Block notification refactoring seems to have had a good 
> effect on performance numbers
>
> Activity
> --------
>
> + Andi
>   - Has been looking at profiles of import and new event creation.
>   - Has been working with Bryan
>   - Rewriting often-used pieces of repository python code in C.
>   - Next up: calendar overlay performance?
>
> + Bryan (Stearns)
>   - Wrote a new performance test for the "Triage" button, and worked with
>     Andi to reduce the time considerably.
>
> + Grant
>   - Looking at getting rid of the effectiveStartTime (computed) 
> attribute,
>     which we seem to spend a fair amount of time calculating.
>   - Looking at the problem of having to change (and eventually commit) 70
>     birefs every time you change selection in the detail view.
>
> + Heikki
>   - Removing stray usage hotshot.Profile.runcall() from performance 
> tests.
>   - General perf test maintenance.
>   - Profiling startup performance.
>   - Comparing "old" and "new" style sharing performance profiles.
>
> + Jeffrey
>   - Looking at reducing the amount of drawing and calculation in the
>     calendar when events change. (possibly in conjunction with John's 
> work
>     below).
>
> + John
>   - Reworking the Block dirty and hints mechanism. As of the α5 
> milestone,
>     Blocks have no way to avoid marking themselves dirty when the item 
> they
>     are displaying changes, which leads to excessive synchronization. In
>     addition, the existing hints mechanism involves Blocks keeping in 
> memory
>     a lot of unneeded information (essentially, a history of all 
> notifications
>     received since the last sync)
>
> + Morgen
>   - Mostly busy doing sharing interop work with cosmo; but wrote scripts
>     to obfuscating personal data for use in tests, and another to 
> generate
>     a hotshot profile for reload (as in "dump and reload") of a large-ish
>     data set (derived from the Office Calendar, I believe).
>
> + Philippe (Bossut)
>   - Looking at some wx drawing optimizations.
>
> + Phillip (pje)
>   - Investigating reload performance, disk space permitting.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev