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

[Grant Baillie]

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.