Community
Participate
Working Groups
OSX 10.2.8 Eclipse: 200309250800 I am finding that the background compilation is hitting performance of the UI very badly, I am seeing lots of spinning beach balls not only when I save but during normal editing as well. I would like an option to do compilation in the foreground if possible. I could turn off autobuild but I really like it. Channing
More generally (at least on Windows 2000), all background activity seem to take all CPU.
I am not seeing this behaviour on Windows 2000. We do run all background threads at a slightly lower priority (like the java index manager does), but it's possible that the threading implementation on Mac doesn't honour this (the Java threading model makes no guarantees about thread scheduling or priorities). On Windows I see some UI performance degradation when there is alot of background activity (for example, CVS auto-refresh and background build), but not enough to want me to turn off background activity (IMO, some degradation is better than a modal dialog that doesn't let me do *anything* while a build is happening). Mike, what has your experience been on Mac so far?
I'm finding that this build has generally worse performance in the UI. Things like code completion is much slower - slow enough for the beach ball to appear waiting for the pop up to appear. I tried turning off autobuilding which helped a bit but not significantly so I am beginning to suspect something else may be responsible. Is there anything I could do to help establish what the trouble may be? Channing
I think I narrowed it down: it is only when the Progress view is visible (i.e. it is the top one on a stack of views) that I see the degradation in performance.
Not for me, progress view is not open.
I entered bug 43758 for the problem with the Progress view on Win2000.
I'm confused. If the best you could do was *wait* before. Presumably, "able to continue, but UI is being impacted" is better. In any case, we are now at the point where we can *begin* to look at those issues. It's clear that tuning for performance is still required. I'm running a Mac. For me the performance has felt the same (or at least close enough that I haven't noticed) when background jobs are *not* running and "slow but acceptable" when they are.
For me, I am not able to continue. For example, after saving, for a about a second nothing happens, and then i get a beach ball for up to 10 seconds. During normal editing I get frequent freezes/beach balls; and opening things like completion can take up to 10 seconds again. Channing
So, you have no background jobs going and you open a file and it's significantly slower than it was? That seems odd, because the code path should be the same as it was. In any case, we *are* going to work on this. The rest of today is shot, here. We'll look at it next week. We're going to have to manage the fact that on really slow platforms, you can't effectively run *anything* in the background.
I'll take a look at the specific cases you are seeing on my machine over the weekend. I can compare against the M3 build.
I have no background jobs. Thanks for looking at it. Channing
I have noticed several occurances this weekend of *significant* delays when switching between editor tabs. We're talking 20 seconds at least, and once > 1min. The delays did not seem to be coincident with background jobs according to the progress indicator. I was unable to find a repeatable case to make them occur, but they seemed to be more prevalent when switching to some *other* tab after a file had just been opened. [related to java indexing or some other system job?] We need to understand what is going on here and fix it. The goal of the responsive UI work is to make the UI *more* responsive.
Since Channing is noticing a slowdown when there is no background activity, this might be (at leasty partially) caused by the problem described in bug 43766. The UI thread is reconciling the compilation unit when I believe it shouldn't. The text team has fixed one of the cases (when breakpoints are added) and I'm following up on a second one. This affects in particular the performance of document save and revert. I'm not noticing a slowdown in content assist at all. Channing, any details you can provide would be useful: - is it on all content assists? - only on large files? - if you repeatedly invoke content assist at the same position, are subsequent attempts much faster than the first?
I am currently seeing long delays when doing Synchronize with Repository... I saw this intermittently earlier today, but they seem to be happening every time now.
The main performance problem I experience occurs during normal editing - when I am saving fairly often whilst coding. After saving, there is an initial pause which may be long enough for the wait cursor to appear, then a small break < 1 second, and then a long period when the compilation is happening in the background but the UI is frozen. The messages I see in the bottom left are "Update for decoration completion" and "building workspace". But that may be erroneous since the whole UI is locked up during this period. To find out more, I started with a complete fresh install and rebuilt my project, which has improved things since my first bug report. (Also, I had previously installed a plugin to edit velocity macro files which had terrible performance and I think was effecting what I was seeing.) Content assist is behaving normally now. File size does not seem to be a factor but all my classes are fairly small. Sorry that I cannot be more definite about whats happening, its hard to pin down. Channing
After each save there is an auto-build. That should be taking approximately the amount of time that it used to, and if you can't do anything while that is happening, that's not any different than before (when it was modal). However, the whole point of the exercise was to allow you to actually *do* something while the compile was happening. It may just be that Mac's aren't fast enough to support this. You also indicate that there is an initial delay where events are not be processed (spinning ball). I'd like to know what is happening then. What kind of Mac are you running, Channing? Do you still have the progress view open? Do things behave differently with it closed?
My mac is a power mac G4, 733 MHz processor, 1 Gb ram. I'd be surprised if this was the problem since it happily runs oracle, mysql, tomcat and eclipse while I'm developing. Shutting them all down made no difference to eclipse performance though. Having the progress view closed makes no difference. Channing
Could this have anything to do with the new Synchronize view? I've been having similar problems since installing 200309250800. They got particularly bad today when our CVS server was taken down; every time the synchronize view wanted to connect to the server, I had to wait for the socket timeout before I got control back. Closing the synchronize view in the open perspective didn't help, however (I still get socket timeouts in the log, so I guess the synchronization is still running somewhere) Lance
Lance, that sounds like a different problem. Please enter a new bug report against Platform VCM for that.
Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=43925 Lance
I have just tried build 200309300800 and the UI is considerably slower than build 00309250800 - unusable now :-( I use the java browser perpective; just clicking on items in the projects, packages or types views takes up to 10 seconds just to highlight the selection. Turning off autobuild doesn't help so I suspect something else is wrong. I have noticed that eclipse now uses significantly more CPU (just visual inspection of a cp usage graph) than it used to when doing anything. Double clicking to open files also does not work so I'll raise bug but I suspect its related to this? Channing
Channing, do you know how to generate java thread dumps on the mac? It's just Ctrl-Break in the Java console on windows, or kill -3 on most unixes. If you can, generate a few thread dumps from the periods when Eclipse is not responsive. That would help me track down what's happening. Also, you might want to try the N20031002 to see how it behaves - we released a few performance fixes yesterday. I don't know if they're related to the slowness you're seeing, but it would help us narrow down the set of possible culprits. Of course, take the usual precautions of using a nightly build - don't trust it with the only copy of your important data!
John, I'll try what you suggest, although I'm not sure how to generate a thread dump on macs - I'll look it up. Channing
I'm having difficulty starting eclipse on the command line, I tried this: % java -cp startup.jar org.eclipse.core.launcher.Main -consolelog -showlocation -data workspace - debug Using the installation directory. Startup: using configuration file:/Users/channingwalton/java/eclipse.200309300800/.config/ platform.cfg Boot URL: file:/Users/channingwalton/java/eclipse.200309300800/plugins/org.eclipse.core.boot_3.0.0/ boot.jar Workspace location: workspace Debug-Options: file:/Users/channingwalton/java/eclipse.200309300800/.options Install URL: file:/Users/channingwalton/java/eclipse.200309300800/ % The stack in the log: !ENTRY org.eclipse.core.launcher 4 0 Oct 02, 2003 22:29:42.212 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Synchronizer at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590) at java.lang.Class.getConstructor0(Class.java:1762) at java.lang.Class.newInstance0(Class.java:276) at java.lang.Class.newInstance(Class.java:259) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(PluginDescriptor.java:138) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(PluginDescriptor.java:179) at org.eclipse.core.internal.plugins.ConfigurationElement.createExecutableExtension(ConfigurationElement .java:103) at org.eclipse.core.internal.runtime.InternalPlatform.loaderGetRunnable(InternalPlatform.java:589) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.internal.boot.InternalBootLoader.getRunnable(InternalBootLoader.java:471) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:854) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:298) at org.eclipse.core.launcher.Main.run(Main.java:764) at org.eclipse.core.launcher.Main.main(Main.java:598) Any ideas?
You don't have to start Eclipse from the command line in order to get thread dumps. Start Eclipse, and start the MacOS X Console. Do a "ps -ax". There should be two lines similar to these: 404 ?? S 0:00.06 /HD/Eclipse.app/Contents/MacOS/eclipse -psn_0_1441793 407 ?? S 11:48.01 /HD/Eclipse/eclipseI0930+/Eclipse.app/Contents/MacOS/java_swt -Xms30M -Xmx150M -cp /Volumes/HD/Ec Use the process id of the "java_swt" process (here 407) and do a "kill -3 <pid>" Now you should get a full thread dump on the console.
Thanks Andre, I was looking in the wrong place for the thread dump.
John, N20031002 didn't build properly and fails to launch as a result so I cannot test it.
The M4 build is next week. I believe it is critical that we find and fix this problem before then.
I don't think there is a single problem we are able to fix for M4. On slower Macs where UI responsiveness is always at its limit, it does not seem to be a good idea to try to make the UI more responsive by running CPU and I/O intensive processing in the background. I suggest to introduce a new preference to disable background builds (but keep auto build).
Hi Andre. My Mac is a dual 800 MHz G4 Quicksilver and I see this problem so I don't think it's to do with 'slow' Macs (Channing will soon have a dual G5, so he might not care any more :-) I strongly believe this problem is to do with repository synchronisation since I only see it when I have the background synching enabled. Regards, Lance
I have a 'slow' G4 PB with 800MHz. With the exception of background builds I have all background activities turned off. However, I cannot continue to work in foreground if the system is building in background. And even worse, background builds now take longer than foregound builds. So I have to wait longer than before.
Something else to add to the confusion: after my attempt with 200309300800 in which selecting items in the gui took up to 10 seconds, I tried again. This time its actually performing much better and I have been using this build reasonably happily if all background stuff is off. Channing
Don't know if this helps but I managed to get a thread dump during a long freeze. I had just selected a Project in the Projects View to see all its problems (my filter for problems was selected resource and children). Here it is: Full thread dump Java HotSpot(TM) Client VM (1.4.1_01-24 mixed mode): "Worker-166" prio=6 tid=0x0a56f760 nid=0xb1a9130 in Object.wait() [f058a000..f058ab70] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108) - locked <0x62ac2ac8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:134) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "Worker-165" prio=6 tid=0x0a7cad60 nid=0xaf1bb80 in Object.wait() [f0e1b000..f0e1bb70] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108) - locked <0x62ac2ac8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:134) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "Worker-164" prio=6 tid=0x0a579250 nid=0xaf1b8d0 in Object.wait() [f0488000..f0488b70] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108) - locked <0x62ac2ac8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:134) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "Worker-161" prio=6 tid=0x0a976980 nid=0xb1c04c0 in Object.wait() [f080f000..f080fb70] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108) - locked <0x62ac2ac8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:134) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) "Thread-52" daemon prio=6 tid=0x095e55d0 nid=0x8a684a0 runnable [f0d9a000..f0d9ab70] at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353) - locked <0x639f74e8> (a java.net.PlainSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:439) at java.net.ServerSocket.accept(ServerSocket.java:410) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:10 7) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:356) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:529) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:554) "Thread-51" daemon prio=6 tid=0x095e4b90 nid=0x8cd6480 in Object.wait() [f0d19000..f0d19b70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:595) - locked <0x63ba8108> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:554) "Thread-50" daemon prio=6 tid=0x095e4950 nid=0x8c27730 in Object.wait() [f0c98000..f0c98b70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:595) - locked <0x63ba8180> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:554) "Thread-49" daemon prio=6 tid=0x095e4730 nid=0x8244b00 in Object.wait() [f060b000..f060bb70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:595) - locked <0x63ba81f8> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:554) "StandardManager[/help]" daemon prio=6 tid=0x095de390 nid=0x8f509f0 waiting on condition [f0a94000..f0a94b70] at java.lang.Thread.sleep(Native Method) at org.apache.catalina.session.StandardManager.threadSleep(StandardManager.java:810) at org.apache.catalina.session.StandardManager.run(StandardManager.java:869) at java.lang.Thread.run(Thread.java:554) "MonitorRunnable" daemon prio=6 tid=0x08e6a0f0 nid=0x8a5dcd0 in Object.wait() [f0a13000..f0a13b70] at java.lang.Object.wait(Native Method) - waiting on <0x639f7468> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable) at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:503) - locked <0x639f7468> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable) at java.lang.Thread.run(Thread.java:554) "Thread-47" daemon prio=6 tid=0x08e69690 nid=0x8a5da70 in Object.wait() [f0992000..f0992b70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:595) - locked <0x639f75d0> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:554) "Thread-46" daemon prio=6 tid=0x08e68c50 nid=0x8f28d60 in Object.wait() [f0911000..f0911b70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:595) - locked <0x639f7648> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:554) "Thread-45" daemon prio=6 tid=0x08e68610 nid=0x8f28b00 in Object.wait() [f0890000..f0890b70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:595) - locked <0x639f76c0> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:554) "Thread-44" daemon prio=6 tid=0x08e68380 nid=0x8f50790 in Object.wait() [f070d000..f070db70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:595) - locked <0x639f7738> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:554) "StandardManager[]" daemon prio=6 tid=0x08e64190 nid=0x8f48180 waiting on condition [f068c000..f068cb70] at java.lang.Thread.sleep(Native Method) at org.apache.catalina.session.StandardManager.threadSleep(StandardManager.java:810) at org.apache.catalina.session.StandardManager.run(StandardManager.java:869) at java.lang.Thread.run(Thread.java:554) "Java indexing" daemon prio=4 tid=0x06194f00 nid=0x5e7d9b0 in Object.wait() [f0509000..f0509b70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:358) - locked <0x62d2e818> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager) at java.lang.Thread.run(Thread.java:554) "Signal Dispatcher" daemon prio=10 tid=0x00106db0 nid=0x83ab0 waiting on condition [0..0] "Finalizer" daemon prio=8 tid=0x00103170 nid=0x833b0 in Object.wait() [f0203000..f0203b70] at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0x62abb970> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x001025e0 nid=0x82820 in Object.wait() [f0182000..f0182b70] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113) - locked <0x62abb9d8> (a java.lang.ref.Reference$Lock) "main" prio=5 tid=0x000f9de0 nid=0xa0000dec runnable [bfffe000..bffff5e8] at org.eclipse.swt.widgets.Tree.getItems(Tree.java:564) at org.eclipse.swt.widgets.Tree.getItems(Tree.java:558) at org.eclipse.jface.viewers.TreeViewer.getChildren(TreeViewer.java:114) at org.eclipse.jface.viewers.AbstractTreeViewer.createAddedElement(AbstractTreeViewer.java:172) at org.eclipse.jface.viewers.AbstractTreeViewer.add(AbstractTreeViewer.java:156) at org.eclipse.ui.internal.progress.ProgressContentProvider$1.runInUIThread(ProgressContentProvider.java: 269) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:81) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:102) - locked <0x6215a6b8> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2074) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1900) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2106) at org.eclipse.ui.internal.Workbench.run(Workbench.java:2089) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:858) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:298) at org.eclipse.core.launcher.Main.run(Main.java:764) at org.eclipse.core.launcher.Main.main(Main.java:598) "VM Thread" prio=5 tid=0x001014e0 nid=0x825a0 runnable "VM Periodic Task Thread" prio=10 tid=0x001064b0 nid=0x83850 waiting on condition "Exception Catcher Thread" prio=10 tid=0x000fa8c0 nid=0x79860 runnable
Channing, stack traces like this are very useful. Feel free to attach more when you get further freezes so we can figure out if there is a pattern. The bug report will be more readable if you create attachments for these traces rather than pasting directly into the comment field (use the "Create a New Attachment" link near the top). There are a half dozen tomcat threads running, I assume this is due to some additional plugins and not one of the base SDK plugins. In any case they all appear to be idle so it shouldn't have too much effect. Thanks for bearing with us!
Hi, I will attach future stacks - sorry about that. I have no plugin that uses tomcat - is it the help system? I am using tomcat on the command line though but that shoudn't have anything to do with it (unless its OSX shared library thing?) I have been using the latest integration release for the last couple of days with synchronization turned off and haven't had any real performance problems. I am going to turn it back on and see what happens. Channing
Suspect tomcat threads may be from help.
Created attachment 6357 [details] Thread dump during and after UI locked up The attached is the thread dump during and just after the UI locked up for. Eclipse returned to the state I first experienced with sever delays switching between editors and editing in general - wait cursors for just about anything. channing
I realised that I should qualify what I mean by 'after UI lock up'. After the UI has locked up, I can move the cursor, and perhaps scroll lists without trouble. If I start to type, move to another editor, open new files, then the UI will lock for a while again. Channing
Could the Java editor be waiting on a resource owned by the background build?
I turned the autobuild off and it made no difference to me.
I think this is just an example of WAAAAY to much work being done when it shouldn't be. Here is the chain of events causing the "freeze" in Channing's latest trace: - user double clicks in editor - selection change is fired to all listeners in the workbench page - marker view listens to selection change - marker view refilters itself, to show only markers in the current selection - since the current selection is a text selection, marker view uses the editor input as the selection -- so it's the java file (compilation unit) - there is an adapter so that selections can tell the marker view if they contain a given marker - compilation unit is asked if it contains a given marker - a java model object is created to represent the compilation unit - first, the java model checks if the compilation unit is on the classpath... this involves parsing the java file to determine the package name. So, what we have is the possibility of a java file being parsed whenever the selection changes in an editor. I am continuing to investigate to decide where this performance bug should go. Channing, in the meantime, try either closing the tasks/problems views, or turning off the filtering based on selection. This appears to be what's killing you.
John, thats it! If i turn off filtering the performance is good, turn it on and its bad. It didn't even occur to me that it might be the problem :-)
I've just discovered it was reported by someone else and just fixed a couple of hours ago! See bug 44069. Apparently a fix is in for M4. I'm going to leave this open for now. Channing, thanks again for the stack traces. If you have any more performance problems you can add more details here and I'll investigate.
Excellent, I hope thats it. Performance feels quite good now. Channing
Philippe, is the parsing really necessary to obtain a CU element?
No parsing is involved here. It is simply tokenizing the file name when creating a unit handle. The rational is that it wants to eliminate up front creation of invalid unit handles (name != identifier). I would love to get rid of this sanity check, but this was already in 1.0...
Sorry, is it tokenizing the file name (no file reading involved) or tokenizing the package declaration (have to read the file)?
Just the file name
Sorry, I was fooled because I saw the Scanner was being invoked in the stack trace. Still seems like a lot of work... I'll try some profiling with today's build to see where the bulk of the time is going when the marker view is filtered on selection.
The degradation problem with the Problems View was in build I20030930+ only (so it would not have been present in 20030925) (bug 39436). However, there is another problem with the filtering mechanism in the Problems view that would cause performance issues (bug 44443 - Problems View should 'filter' more efficiently). This problem has been around since the creation of the Problems view.
I posted a patch of JDTCore so as to not validate file names when creating handles (also see bug 44462). This isn't released in M4. Will be for early M5. See patch posted in update area: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r3.0/main.html#updates
Just to clarify, the patch will avoid all scanning issues which were visible in the thread dump. Hope this helps.
Profiling of the behaviour in M4 shows that the main problem with the problems view is fixed. I'm seeing minimal time updating the marker view on selection changes in the java editor. Philippe's optimization is no longer needed in this case since the code path that it optimizes is no longer being hit as often. There are still times where the marker view is doing redundant refreshes (bug 44443 has more details), but it isn't showing up in this case. I did some more profiling, and found that in certain situations the key binding filtering is creating almost 1 MB of garbage per key press (entered bug 44864 for this). It's likely that this has also been contributing to general slowness in the editor. I'm going to close this particular bug since it no longer has a clear case showing regression. Channing (and others): please enter new bug reports if/when you experience new slow spots on the Mac. The stack traces help greatly in narrowing down the issues.
