[Chandler-dev] [Proposal] 3 Possible Hacks to Improve Performance

[Grant Baillie]

Hi, Mimi

Comments inline ...

--Grant

On 9 Jul, 2008, at 05:17, Mimi Yin wrote:

> I know it's the 11th hour to bring up this kind of thing, but  
> Keith's suggestion reminded of a different "performance-improvement"  
> hack we discussed pre-Preview: to limit the amount of "legacy"  
> calendar data we import and get rid of anything "older than a year".
>
> So there are 3 things we might be able to do to alleviate  
> performance pain:
>
> 1. Replace weekly auto-purge with auto-export/reload. (Would this  
> actually help?)

Probably. In a way, auto-export/reload is like a more thorough auto- 
purge (but I believe it runs faster ;). There is some cached sharing  
data we lose on export/reload, so potentially there might be  
regressions introduced there. Personally, I export/reload more  
frequently than most people, and I haven't noticed anything  
particularly untoward.

> 2. Auto-archive anything that was triaged to DONE more than 1 year??  
> ago
> - The simplest way to do this might be to take a snapshot of your  
> data, export it to an Archive.chex file that is timestamped so that  
> if you ever need it, you can always reload it into Chandler to take  
> a look at it.
> - We could eventually add a File menu item that allowed you to  
> switch easily between archived data sets and your current data set.  
> (Sort of like the way Andi's repo-switch feature worked.)

Sure, this is possible, and not too difficult, though I'm not sure you  
want Archive.chex files piling up automatically.

> 3. Discard anything older than 1 year
>
> Of course, all of these things would be optional (except for maybe  
> #1) accompanied by an explanation that if you feel like Chandler is  
> getting sluggish, you should do them.

This is technically possible, but I believe it would take several days  
to debug and test.

> ****
> I'm loathe to start up a conversation about more features at this  
> point in the process, but given the feedback we've received on  
> performance, does 1.0 need to demonstrate some concrete progress on  
> performance since Preview? Would the above fixes help the people who  
> are feeling performance pain today? Or are they not likely to  
> improve the situation by very much?

This is the $1,000,000 dollar question, eh. Sounds as if you asked the  
audience :).

--Grant