Community
Participate
Working Groups
Currently, the on-the-fly error checker runs after every keystroke. This makes typing horribly slow when dealing with large files (>1000 lines), and I usually end up having to disable it. It would be better if the checker waited for me to stop typing before running. This would be good for two reasons: better performance, and I don't care about errors while I'm typing (I'm not done the statement yet!). This would be done by starting a reseting a timer after every keystroke, and only running the checker once the timer fires. Preferrably the interval of the timer would be user definable. This is how JBuilder does it, and I found it to work quite well.
In 20020502 the editor cannot fully keep up with typing in larger CUs when temporary problems are enabled. The test case used was PackageExplorerPart.java on my TP600X. Experimented with increasing the reconciling delay to 1000ms with no perceived performance improvements.
Error detection does not start if the user types. When stopping it starts after a delay of 500ms. If the user starts typing, any running error detection is canceled. Build 20020508.
Editing large files in build 0510 still causes 100% CPU utilization while typing.
What is your concrete scenerio? Typing in StyledText.java (8000 loc) having all import statements removed (> 1000 errors) causes an average CPU load of 13%. There are short peaks of almost 100% when all temporary problem annotations are set, 500ms after you stop typing.
I've tried with several files, ranging from 1000 to over 2000 lines. The number of errors doesn't have a percievable impact. It does indeed seem to wait 500ms before processing, but it also seems like the timer isn't reseting when I continue to type. I cannot release the concrete file, but I can reproduce this on any number of large files. Updated report to specify this is on Windows 2000.
I observe the same problem in the PackageExplorerPart scenario on my TP. The CPU is up to 100% even when I continue typing and the reconciling should have been preempted.
Using build 20020521 (1pm) It seems to be the "Synchronize outline selection on cursor move" preference that kills the performance. If I turn that off, CPU usage hovers around 30% while typing. If I turn it on, it hovers around 100% while typing (and the cursor can't keep up as I type). This is on a 1.4Ghz PIV with 512MB RAM.
This issue is still present in the F1 build. Even when i switch off the outline synchronization. Tested with W2k and JDK1.4 and several java files with a length of more than 2500 lines.
The reconciling is now pre-emptive but there are some scenarios where a reconcile is triggered in the UI thread: * "synchronize outline selection on cursor move" calls getElementAt. Workaround disable the preference close and reopen the editor * the text hover can kick in and trigger a reconcile. Workaround is to disable the text hover. * the breakpoint action triggers an unneeded reconcile on selection changes (see 17162)
synchronizeOutlinePageSelection in the compilation unit editor no longer reconciles the compilation unit. If reconciling would be necessary, the method is a noop. This is ok as the reconciler will run or is about to run and thus all reconciling participants will be called in the near future. The text hover infrastructure has been changed to compute the hover information in a separate dedicated thread.
In F1 still slow even if "synchronize outline selection on cursor move" and "text hover" are off. Now some times when typing cr there are several seconds delays.
In build 20020528 I don't see any delays in the editor if I turn off reconciling and text hovers. If not, I still get some delays, especially when working with blocks of text (indenting, pasting).
After starting a new Eclipse (F1) session things go better.
Further changes for F2: - text hovering changed so that the hover only gets reactivated when leaving its previous hover region - more strict cancellation of found temporary problems - not directly related to typing: (shifting, commenting, replace) now work on a special optimized code store Overall, typing delays have been perceivably reduced by avoiding any significant work in the UI thread. There are still problems with the cancellation behavior of the Java reconciler. I.e, its resonse time to cancellation requests is too long.
Performance is much better now. There are still two operations I've found that are problematic: Block indenting/unindenting, and commenting/uncommenting. When these operation are performed repeatedly (ie: holding down the hotkeys), the editor doesn't repaint until you release the key(s). This is in build 0602. Other than that (which is a fairly rare case), things are looking much better.
Closed. Remaining issues in #23149.
