Community
Participate
Working Groups
The below are the two scenarios in both Juno(8.1.2) and Kepler (8.3.0): 1. While modifying a large file (e.g., first.c) and if we try to single-click/double-click on the variables, it is taking nearly 1 min time to highlight all the occurrences. If my next action is marking other word, then it is very fast.(My successive markings are fast until I modify or type something in the file). Now If I type anything, again it repeats 1 min lag. 2. While modifying a large file, when we switch from this large file to another file, single-click/double-click on the variables are taking longer times to highlight them. My successive markings are fast until I switch to another file and back to large file. Below are the detailed steps that I followed to reproduce the problem. a. Checked-out few large files, first.c, second.c. b. Added few comments in first.c and didn't saved the latest comments. c. Now double-clicked on one of the variable, 'DummyResGlobal'. It took 36 sec to highlight all the occurrences. d. Again double-clicked on another variable 'NILPTR'. It took only 1 sec to highlight all the occurrences. e. Now added few lines of code in first.c and double-clicked on 'DrvTblFncRet' variable which took 34 sec to highlight. f. Switched to second.c and added some spaces there and came back to first.c. When I try to single-click on 'NILPTR', it took 36 sec to highlight.
It seems this problem is fixed in CDT (7.0) but not working in Juno(8.1.2) and Kepler (8.3.0). https://bugs.eclipse.org/bugs/show_bug.cgi?id=314635
Could you create a thread dump during the 1 min delay? Details are here: https://wiki.eclipse.org/How_to_report_a_deadlock From the description it sounds like the parser is slow on parsing the file, because the delay only occurs after a modification.
1.Eclipse Build: Eclipse IDE for C/C++ Developers Version: Kepler Service Release 2 Build id: 20140224-0627 2. Java Version and Vendor: java version "1.6.0_45" Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode) 3. Operation performed: Double-clicking on a variable to highlight all the occurrences. 4. JVM configuration: eclipse.vmargs=-Dosgi.requiredJavaVersion=1.6 -XX:MaxPermSize=256m -Xms40m -Xmx512m -XX:MaxPermSize=512m -Xms4096m -Xmx4096m 5. RAM and SWAP info: hysue801:sc186002--> free -g total used free shared buffers cached Mem: 70 67 3 0 0 5 -/+ buffers/cache: 62 8 Swap: 143 0 143 6. Reproducible Steps: a. Checked-out few large files, first.c, second.c. b. Added few comments in first.c and didn't saved the latest comments. c. Now double-clicked on one of the variable, 'DummyResGlobal'. It took 36 sec to highlight all the occurrences. d. Again double-clicked on another variable 'NILPTR'. It took only 1 sec to highlight all the occurrences. e. Now added few lines of code in first.c and double-clicked on 'DrvTblFncRet' variable which took 34 sec to highlight. f. Switched to second.c and added some spaces there and came back to first.c. When I try to single-click on 'NILPTR', it took 36 sec to highlight. 7. Enclosing four thread dumps taken with a gap of few seconds using jvisualvm. a. threaddump-1404887963632_just_after_double_click.tdump b. threaddump-1404887987358_after_20_sec.tdump c. threaddump-1404888009049_after_40_sec.tdump d. threaddump-1404888038222_after_highlight.tdump Please let me know if you need any further info. Thanks in advance.
Created attachment 244907 [details] Thread dump taken immediately when I double-click on the variable.
Created attachment 244908 [details] Thread dump taken after 20 sec of double-click operation on a variable.
Created attachment 244909 [details] Thread dump taken after 40 sec of double-click operation on a variable.
Created attachment 244910 [details] Thread dump taken after the variable is highlighted on all occurrences.
Thanks for the thread dumps. It looks like semantic highlighting and codan checkers are using most of the time. How large are the files in question? For large files (by default 5000+ lines) we have the scalability mode to avoid those known performance issues. Does it help to disable semantic highlighting in the preferences?
Thank you for your quick response. The file has more than 40000 lines of code and the file size is more than 1.5MB. No performance issues for the smaller files (1000 lines). Disabled the semantic highlighting but it doesn't help. Enabled the scalability mode when the number of lines in the file is more than 50000. Increasing or decreasing this scalability value also did not solve the performance problem.
(In reply to csk 200 from comment #9) > Enabled the scalability mode when the number of lines in the file is more > than 50000. Increasing or decreasing this scalability value also did not > solve the performance problem. Of course you should set the value to something lower than your file size. Try the default of 5000 lines. Note that you have to close and reopen the file for the scalability options to take effect.
(In reply to Anton Leherbauer from comment #10) > (In reply to csk 200 from comment #9) > > Enabled the scalability mode when the number of lines in the file is more > > than 50000. Increasing or decreasing this scalability value also did not > > solve the performance problem. > > Of course you should set the value to something lower than your file size. > Try the default of 5000 lines. > Note that you have to close and reopen the file for the scalability options > to take effect. No change in the performance even for default 5000 lines. Yes, I'm closing and reopening the file and verifying. Actually to avoid the scalability popup, we set to bigger number in the preferences.
(In reply to csk 200 from comment #11) > No change in the performance even for default 5000 lines. Note that with default scalability settings, in particular disabled live-parsing, you loose also the mark occurrences feature. I.e. it is no surprise that occurrences are not highlighted in this case. If you instead disable only semantic highlighting (but keep live-parsing enabled), mark occurrences should still work. > Actually to avoid the scalability > popup, we set to bigger number in the preferences. But that also defeats the purpose of the scalability mode. You can avoid the popup without changing the number of lines limit.
(In reply to Anton Leherbauer from comment #12) > If you instead disable only semantic highlighting (but keep live-parsing > enabled), mark occurrences should still work. Still the mark occurrences takes 30 to 40sec. > But that also defeats the purpose of the scalability mode. You can avoid > the popup without changing the number of lines limit. How to avoid the popup?
Can we expect any patch/fix for this performance issue?
