[Chandler-dev] Commitment (Was: Problem with stamping and collection notifications/ kind watchers)

[Grant Baillie]

On 18 Jul, 2006, at 17:33, Bryan Stearns wrote:

> Travis Vachon wrote:
>> Bryan, one other note: you mentioned at one point that you could  
>> put a
>> commit back in after stamping happens. This seems to make sense,  
>> and if
>> there are no objections, it would be convenient for me to have  
>> this happen.
>>
> Travis,
>
> The objection comes from the performance tests: stamping will get  
> even slower. As it is, the 3000 event calendar stamping test takes  
> 200% of the current goal. Last time I tried, it took me more than  
> three days work to find a way to make it about 15% faster, and I  
> don't know of anything else to rework to improve it further.
>
> I could cheat and reduce the apparent impact of this during the  
> automated tests by forcing a commit before the timing starts, but  
> it'll still be a fair bit slower than it is now, and I'm unable to  
> do this with the current goal. (This is cheating because the user  
> will still see the stamping operation include all the time to  
> commit anything the user has done since the last commit - it'll  
> look even slower still!)

In general, when does the UI commit changes?

Although committing after every user operation has a significant  
performance downside, there are reliability advantages (*):

1) Less chance of data loss if the app/user's machine crashes
2) Data is reasonably up-to-date in background sync operations

--Grant

(*) Maybe these are beta-quality reliability constraints, though.