Community
Participate
Working Groups
STEPS TO REPRODUCE: 1.) Check out Workbench.java from HEAD 2.) Use one of the new code formatter options to introduce a bunch of little changes 3.) Change to the synchronize view 4.) Compare with HEAD OBSERVED RESULTS: The dialog makes a small amount of progress and then appears to hang. There are no visual cues that work is still progressing. When the work finally does complete (quite a long time later), the progress bar is still hovering at slightly below half.
If i compare a large text files (1,3 MB) Eclipse goes out of memory. I gave Eclipse 1GB memory. This worked fine in Eclipse 2.1.
*** Bug 66384 has been marked as a duplicate of this bug. ***
Re #1: The compare algorithm hasn't changed between 2.1 and 3.0, however other parts of the system have. For analyzing this problem I need some more information: - are you running Eclipse with the default heap sizes, or do you specify a larger heapsize (e.g. -Xmx250M) - when does Eclipse run out of memory? While performing the compare or when loading it into the compare editor? - is it reproducable? - does it happen if the compare is the first thing you do after starting Eclipse?
Re #1: - did you try to turn on the "Ignore whitespace" option for the compare? This helps a lot if you have lots of formatting changes. You find the option in the Compare editor's toolbar.
I did not see an out of memory error. Just a long pause -- if I remember correctly, with no user interface painting. Heap size was 256MB. And, no I wasn't ignoring white space. For me, the issue isn't the algorithm itself, but the fact that it appears as though the system has hung.
Douglas, you've filed the bug in January. At that time the compare algorithm blocked the UI for two seconds (showing just a busy cursor), and then opened a progress dialog (with its own event loop). Recently this strategy has been changed to use the ProgressService.run(true, true, ...). Could you please verify that this makes the UI more responsive? (however, this does not fix the issue that the initial guess for the amount of work is bad).
This issue seems largely resolved. I opened Workbench, sorted its members and formatted the entire file. This creates a rather large diff. I then double-clicked on the item in the synchronize view. Progress bars appeared for the separate stages of the operation (e.g., downloading the file, computing differences, etc.). The UI immediately responded with a busy cursor when I double-clicked. The user interface painted while the compare was going on. The compare also seemed to be faster then I remember it being when I filed this bug (much faster). The only issue that remains is that computation of the size of the progress bar is still off. The task completes when the bar is slightly below the halfway mark. This is relatively minor compared to the original sensation that the system had hung. This bug could be deferred from RC3, and it might also be possible to just close this bug at this point -- depending on whether you want to work on perfecting the size of the bar.
Thanks Douglas. I've created bug #67800 (RangeDifferencer progress reporting stops at 50%) to track the incorrect progress reporting. Issues with large memory consumption and slow performance are already addressed by #9203. Closing as suggested in comment #7.
In my opinion this should not have been marked as WORKSFORME since the steps show that it currently does not work correctly (hence the two bugs which are still not marked as fixed). However, the resolution of the bug itself is done and hence marking as verified. Marked the two mentioned bugs as blocking this one.
