[Dev] Re: code review

[John Anderson]

I forgot to mention that I suspect that DeleteSelection is slow because 
other threads create a bunch of items on startup (e.g. zaoboa) which add 
to the time of the first commit, and if it's DeleteSelection, it's going 
to be slower.

John

John Anderson wrote:

> Hi Alec:
>
> If we use commit points for undo points, then it typically makes sense
> to commit after finishing an undoable operation or commit the last
> operation before starting an undoable operation in the UI thread. I
> think DeleteSelection is an undoable operation, so I think the commit is
> appropriate -- not the refresh.
>
> I suspect the reason the commit might be so slow isn't because of the
> items that were deleted by DeleteSelection, but instead, all the other
> items that were changed in other threads or as part of startup. So I
> think when we're done with startup we should do a refresh in the UI
> thread and when other threads have items for us they should notify the
> UI thread to do a refresh. This would solve the performance problem if
> it isn't the items deleted and make undo possible for not much effort.
> However, it's slow because committing the items changed by
> DeleteSelection is slow, then the solution isn't to avoid commit, the
> solution is to speed up commit.
>
> If this is confusing I'd be happy to go over it on a white board when
> we're both at OSAF
>
> John
>
>
> Alec Flett wrote:
>
>> Hey John -
>> I've got a fix for two bugs in one patch:
>> http://bugzilla.osafoundation.org/attachment.cgi?id=494&action=edit
>>
>> The two bugs are:
>> http://bugzilla.osafoundation.org/show_bug.cgi?id=2322
>> about switching from commit() to refresh() to gain some performance
>>
>> http://bugzilla.osafoundation.org/show_bug.cgi?id=2090
>> about fixing up the column widths when the grid widget is sychronized
>>
>> Do you mind taking a look? I can explain any of it too but its pretty 
>> small & straight forward...
>>
>> Alec
>
>
>
>
>