[Chandler-dev] Chandler Performance: Who's doing what
rae at osafoundation.org
Fri Apr 13 15:16:00 PDT 2007
The two things I'm looking into are MultiStateBitmap and gradient-
drawing. There are wx updated for the latter that may provide some
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 ...
> + Andi and Bryan came up with two groovy improvements in indexing
> + When an item's position in a sorted index needs to be
> (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
> 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
> + John's Block notification refactoring seems to have had a good
> effect on performance numbers
> + 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)
> 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
> - 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
> + John
> - Reworking the Block dirty and hints mechanism. As of the α5
> 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
> received since the last sync)
> + Morgen
> - Mostly busy doing sharing interop work with cosmo; but wrote
> to obfuscating personal data for use in tests, and another to
> a hotshot profile for reload (as in "dump and reload") of a
> 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.
More information about the chandler-dev