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

[Ted Leung]

Hey Grant,

Thanks for sending this -- it's really inforomative!

Ted

On Apr 12, 2007, at 5:56 PM, 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