[Chandler-dev] Commitment (Was: Problem with stamping and
collection notifications/ kind watchers)
grant at osafoundation.org
Tue Jul 18 17:54:38 PDT 2006
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.
> 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
(*) Maybe these are beta-quality reliability constraints, though.
More information about the chandler-dev