Bug 77893 - Clean Timestamp on project with large number of false changes
Summary: Clean Timestamp on project with large number of false changes
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: CVS (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M4   Edit
Assignee: Michael Valenta CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2004-11-04 15:13 EST by Michael Valenta CLA
Modified: 2004-11-11 14:15 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Valenta CLA 2004-11-04 15:13:59 EST
After the time change, most projects had a large number of outgoing changes. 
Performing a Clean Timestamps on the JDT test projects appeared to freeze the 
UI. A quick inspection of the stacktraces reveal that the UI thread is live 
and is doing work updating the synchronize view. However, the hourglass is up 
and the user cannot do anything.
Comment 1 Michael Valenta CLA 2004-11-08 12:05:14 EST
Investigate for M4
Comment 2 Michael Valenta CLA 2004-11-11 10:50:28 EST
It turns out that there is an optimization in StructuredViewer to use a 
hashmap to speed up access to exisiting elements. I thought this was on by 
default but it is not so we ar enot using it. At the beginning of an 
operation, we mark all involved elements as busy. The viewer does then one at 
a time and each update involves a tree traversal to find the item. I will turn 
on the hash table lookup and see if it helps.
Comment 3 Michael Valenta CLA 2004-11-11 11:11:09 EST
That certainly did the trick. 

However, there was still a pause at the end which was caused by deletions. The 
problem is that we have a remove for a single item that removes the item from 
the model and then from the viewer. We have our own code that will preserve 
the selection and expansion accross the deletion of multiple items but the UI 
also preserves selection so it is happening n times instead of once. We could 
either bypass the selection preservation in the view or batch the view removes 
somehow. The wait is nowhere near as long as it was so it may not be necessary 
to do either but I will investigate how difficult it is to do before closing 
this bug.
Comment 4 Michael Valenta CLA 2004-11-11 14:15:24 EST
Fixed the delete case as well. Delete removals are now batched when possible.