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

[Brian Kirsch]

Hello,
I am currently profiling the message text to Chandler Item conversion  
code in osaf.mail.messages as
improvements here can significantly increase download performance.

This work is part of [Bug 7177] Improve mail download performance and  
repository storage.

I am in the process of writing performance tests for the following  
cases:

1. Downloading a EIMML Message
2. Downloading a EIMML Task
3. Downloading a EIMML Event
4. Downloading a EIMML Recurring Event
5. Downloading a EIMML Task / Event
6. Downloading a MailStamp item from the Chandler Mail folder
7. Downloading a TaskStamp item from the Chandler Tasks folder
8. Downloading a EventStamp item from the Chandler Events folder
9.  Downloading a message containing a .ics Event
10. Downloading a message containing a .ics Recurring Event
11. Downloading a message containing a .ics Task
12. Downloading a message containing a .ics Task / Event


-Brian


Brian Kirsch
Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org







On Apr 13, 2007, at 12:16 PM, Reid Ellis wrote:

> The two things I'm looking into are MultiStateBitmap and gradient- 
> drawing. There are wx updated for the latter that may provide some  
> improvements.
>
> Reid
>
> On Apr 12, 2007, at 20:56, 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