Bugzilla – Full Text Bug Listing
| Summary: | Text selection extremely slow in C++ editor | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] Subversive | Reporter: | rafeek.rahamut | ||||||||||||
| Component: | UI | Assignee: | Igor Burilo <igor.burilo> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | cdtdoug, daniel_megert, igor.burilo, Michael_Rennie, rafeek.rahamut, remy.suen, thatnitind | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
rafeek.rahamut
Is this only when for when editing C/C++ files or do you get this problem when editing regular text files? I don't see it when editing Makefiles, but I believe I saw it with another non C++ file. I don't recall which type of file this was though. We would need to know what kind of file you are trying to edit and what editor it is open in. Can you attach an example file that demonstrates the problem? Created attachment 198652 [details]
C/C+ index (team shared export)
Created attachment 198653 [details]
File that shows problems
This file is located at: ${project}/src/webserver/jsoncpp/json
I added two attachments, one is a file that exhibits the problems, that I can publicly disclose. The other is the C/C++ index file as exported using the Team Shared Export. I tried creating a new file, but it didn't show any issues so it looks as though the problem is specifically for files that are indexed? Although I just found a text file which I'll attach that also shows the problem. Created attachment 198654 [details]
Plain text file that also has issues
located in ${project}/src/webserver/jsoncpp
moving to Platform Text for comment since it is reported the problem happens for 'normal' text files as well as C++ header files. Is the project mounted from the network onto both machines? (In reply to comment #9) > Is the project mounted from the network onto both machines? On the linux machine all files are local. On the Mac OS X machine the workspace (and project) is network mounted from the linux machine, while system includes and such that are found in /usr/ross are local. (In reply to comment #8) > moving to Platform Text for comment since it is reported the problem happens > for 'normal' text files as well as C++ header files. I have not seen a comment that says so (the one from comment 5 is a header file). Moving to CDT for investigation. comment 7 seems to indicate that this occurs with plain text files as well. Could you try opening a C++ file which exposes the slowness in the Text editor (right click > Open with... > Text editor) and see if selection speed changes? Are you running close to max heap? (Enable Preferences > General > Heap Status) Is there any clipboard manager active? (In reply to comment #12) > comment 7 seems to indicate that this occurs with plain text files as well. Sorry, missed that one. How slow is it? If it takes several seconds then you could try to create a stack dump and attach it here. (In reply to comment #12) > Could you try opening a C++ file which exposes the slowness in the Text editor > (right click > Open with... > Text editor) and see if selection speed changes? When I opening the C++ file in the text editor the selection block behaves fine. > > Are you running close to max heap? (Enable Preferences > General > Heap Status) I start with these memory parameters in the eclipse.ini: -Xms512m -Xmx2048m -XX:MaxPermSize=512m -XX:PermSize=400M Heap status says "203M of 513M", the orange bar is about a quarter of the way across, the black bar is a little less than half of that. I'll attach the entire file. > > Is there any clipboard manager active? None that I'm aware of, but I'm by no means a linux power user. I installed Ubuntu 11.04 on this machine myself (fresh install) and didn't deliberately install any clipboard managers. Created attachment 199056 [details]
INI file used for the eclipse instance
(In reply to comment #13) > (In reply to comment #12) > > comment 7 seems to indicate that this occurs with plain text files as well. > Sorry, missed that one. > > How slow is it? If it takes several seconds then you could try to create a > stack dump and attach it here. It can take that long if I'm using the keyboard to extend selection as the keystrokes get queued up. Also when I do this the selection block doesn't visually update until the end, but the cursor moves at about 1 per second. Since I'm not a Java developer I'll need some instruction on how to get the stack trace. > Since I'm not a Java developer I'll need some instruction on how to get the > stack trace.See http://wiki.eclipse.org/index.php/How_to_report_a_deadlock#Getting_a_stack_trace_on_Windows Created attachment 199059 [details]
Series of stack traces.
I used jstack to capture the stack at .2 second intervals while Eclipse was processing a backlog of Shift+DownArrow keys.
The stack traces (see excerpt below) indicate that SVN is the culprit here. What I do not understand is why it would not be slow when opening the same file with the text editor, because the SVN team actions simply listen for selection changes. Can you re-test again and make sure to use the exact same steps? "main" prio=10 tid=0x0000000000cc2000 nid=0x16ff in Object.wait() [0x00007f531523e000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at java.lang.UNIXProcess$Gate.waitForExit(UNIXProcess.java:80) - locked <0x00000007d907f800> (a java.lang.UNIXProcess$Gate) at java.lang.UNIXProcess.<init>(UNIXProcess.java:161) at java.lang.ProcessImpl.start(ProcessImpl.java:81) at java.lang.ProcessBuilder.start(ProcessBuilder.java:468) at java.lang.Runtime.exec(Runtime.java:610) at java.lang.Runtime.exec(Runtime.java:483) at org.eclipse.core.internal.net.proxy.unix.UnixProxyProvider.getEnv(UnixProxyProvider.java:195) - locked <0x0000000782fdb6c0> (a org.eclipse.core.net.ProxyProvider) at org.eclipse.core.internal.net.proxy.unix.UnixProxyProvider.getSystemProxyInfo(UnixProxyProvider.java:135) at org.eclipse.core.internal.net.proxy.unix.UnixProxyProvider.getProxyData(UnixProxyProvider.java:58) at org.eclipse.core.internal.net.AbstractProxyProvider.select(AbstractProxyProvider.java:43) at org.eclipse.core.internal.net.ProxyManager.getProxyDataForHost(ProxyManager.java:366) at org.eclipse.team.svn.core.utility.SVNUtility.configureProxy(SVNUtility.java:814) at org.eclipse.team.svn.core.svnstorage.SVNRepositoryLocation$2.runImpl(SVNRepositoryLocation.java:699) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.svnstorage.SVNRepositoryLocation.fetchRepoInfo(SVNRepositoryLocation.java:695) at org.eclipse.team.svn.core.svnstorage.SVNRepositoryLocation.fetchRepoInfo(SVNRepositoryLocation.java:682) - locked <0x00000007831d7238> (a java.lang.Integer) at org.eclipse.team.svn.core.svnstorage.SVNRepositoryLocation.getRepositoryRootUrl(SVNRepositoryLocation.java:264) at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.asRepositoryResource(SVNRemoteStorage.java:494) at org.eclipse.team.svn.ui.action.local.CompareWithBranchTagAction.isEnabled(CompareWithBranchTagAction.java:50) at org.eclipse.team.internal.ui.actions.TeamAction.setActionEnablement(TeamAction.java:313) at org.eclipse.team.internal.ui.actions.TeamAction.selectionChanged(TeamAction.java:298) at org.eclipse.team.svn.ui.action.AbstractSVNTeamAction.selectionChanged(AbstractSVNTeamAction.java:151) at org.eclipse.ui.internal.PluginAction.refreshEnablement(PluginAction.java:206) at org.eclipse.ui.internal.PluginAction.selectionChanged(PluginAction.java:277) at org.eclipse.ui.internal.PluginAction.selectionChanged(PluginAction.java:299) at org.eclipse.ui.internal.AbstractSelectionService.fireSelection(AbstractSelectionService.java:156) at org.eclipse.ui.internal.AbstractSelectionService$1.selectionChanged(AbstractSelectionService.java:62) (In reply to comment #19) > The stack traces (see excerpt below) indicate that SVN is the culprit here. > What I do not understand is why it would not be slow when opening the same file > with the text editor, because the SVN team actions simply listen for selection > changes. Can you re-test again and make sure to use the exact same steps? I retested, followed the same steps (as far as I know) and the performance in the text editor now matches the performance in the C/C++ editor. I don't know what's different now, I repeated the test a few times, restarting eclipse each time, with many open editor windows and none. Now it's completely consistent... It makes sense that it's because of the SVN module since editing a file not under revision control (e.g. a new C++ file) has no issues. Additional info: I uninstalled all SVN related packages (I was using the native javaHL connector) and then re-installed using the SVNKit connector. Now I'm not seeing the issue. I've made changes so that Subversive won't need to connect the repository while calculating enablements with JavaHL connector either. So, I'll mark the bug as fixed, but for all the interested parties I would like to suggest a question: why is it that menu items enablement is calculated on each key press instead of just before opening the pop-up menu? I'll just say one thing: the actual bug is somewhere else, but I won't press the matter, since I can't reproduce this strange behaviour anyway. :) |