Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 44069

Summary: [Problems View] Time response while debugging slows down when several perspectives are opened
Product: [Eclipse Project] Platform Reporter: Frederic Fusier <frederic_fusier>
Component: UIAssignee: Debbie Wilson <debbie_wilson>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: jerome_lanneluc, john.arthorne, kent_johnson, martinae, Tod_Creasey
Version: 3.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Whiteboard:
Attachments:
Description Flags
Jar file for org.eclipse.ui.views none

Description Frederic Fusier CLA 2003-10-02 07:28:31 EDT 
I used to have several (5 in fact) Plug-in Dvpt or Java perspective windows 
open at the same time while working in Eclipse environment.

Since a while, I've noticed that I got longer time response while working in 
Eclipse and especially while debugging. It took around 30s to launch the 
application in debug mode and same time to end the main debug process after the 
application threads were ended...

After several tries, I close all my "extra" perspective windows and keep only 
one opened. Then launch the same debug session and retrieve "normal" response 
time (1 or 2 seconds).

I think it can come from the Problems view as it was the only view which was 
opened when I have all my perspective windows opened. The number of problems 
displayed in this view were about 80 (warning + errors). Initially, I had 
filter to display only some of these problems, but one of my try to speed up 
the debug process was to remove all the filters... But perhaps this response 
time issue has no relation at all with this view and it comes from elsewhere...

I've also noticed that time responses to start and close debug sessions were 
not always about 30 sec... But what I'm sure is that these times were longer 
when I have several perspective windows opened than when I have only one 
opened...
Comment 1 Frederic Fusier CLA 2003-10-02 07:42:20 EDT 
Here's a Full thread dump to help you in your research (see "main" thread at 
the end):

Full thread dump Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode):

"Worker-20" prio=7 tid=0x17D07C10 nid=0x7d8 in Object.wait() 
[1a67f000..1a67fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <03D5C2B8> (a org.eclipse.core.internal.jobs.WorkerPool)
        at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108)
        - locked <03D5C2B8> (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-19" prio=7 tid=0x17C0BAA0 nid=0x240 in Object.wait() 
[1a3ff000..1a3ffd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <03D5C2B8> (a org.eclipse.core.internal.jobs.WorkerPool)
        at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108)
        - locked <03D5C2B8> (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-18" prio=7 tid=0x17A30908 nid=0x7e8 in Object.wait() 
[1a3af000..1a3afd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <03D5C2B8> (a org.eclipse.core.internal.jobs.WorkerPool)
        at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108)
        - locked <03D5C2B8> (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-17" prio=7 tid=0x17AC2940 nid=0x5ac in Object.wait() 
[1a36f000..1a36fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <03D5C2B8> (a org.eclipse.core.internal.jobs.WorkerPool)
        at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:108)
        - locked <03D5C2B8> (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)

"org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x17C0C530 
nid=0x7f4 in Object.wait() [19c9f000..19c9fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <09817CD8> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)
        at 
org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run
(AbstractReconciler.java:161)
        - locked <09817CD8> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)

"ServerConnection" prio=7 tid=0x17AA6B00 nid=0x57c runnable [1935f000..1935fd88]
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
        - locked <051972C0> (a java.net.PlainSocketImpl)
        at java.net.ServerSocket.implAccept(ServerSocket.java:439)
        at java.net.ServerSocket.accept(ServerSocket.java:410)
        at 
org.eclipse.jdt.internal.junit.ui.RemoteTestRunnerClient$ServerConnection.run
(RemoteTestRunnerClient.java:102)

"ServerConnection" prio=7 tid=0x16C967B0 nid=0x828 runnable [18f9f000..18f9fd88]
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
        - locked <0514E398> (a java.net.PlainSocketImpl)
        at java.net.ServerSocket.implAccept(ServerSocket.java:439)
        at java.net.ServerSocket.accept(ServerSocket.java:410)
        at 
org.eclipse.jdt.internal.junit.ui.RemoteTestRunnerClient$ServerConnection.run
(RemoteTestRunnerClient.java:102)

"org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x16CC0B08 
nid=0x594 in Object.wait() [18aef000..18aefd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <0502A788> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)
        at 
org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run
(AbstractReconciler.java:161)
        - locked <0502A788> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)

"org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x16BFC350 
nid=0x7f0 in Object.wait() [187cf000..187cfd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <04F0B1B0> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)
        at 
org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run
(AbstractReconciler.java:161)
        - locked <04F0B1B0> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)

"org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=2 tid=0x16BFB9E8 
nid=0x8ec in Object.wait() [1847f000..1847fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <04E4C418> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)
        at 
org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run
(AbstractReconciler.java:161)
        - locked <04E4C418> (a 
org.eclipse.jface.text.reconciler.DirtyRegionQueue)

"Java indexing" daemon prio=7 tid=0x16BA3EE8 nid=0x4e8 in Object.wait() 
[1752f000..1752fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <04221088> (a 
org.eclipse.jdt.internal.core.search.indexing.IndexManager)
        at java.lang.Object.wait(Object.java:426)
        at org.eclipse.jdt.internal.core.search.processing.JobManager.run
(JobManager.java:358)
        - locked <04221088> (a 
org.eclipse.jdt.internal.core.search.indexing.IndexManager)
        at java.lang.Thread.run(Thread.java:536)

"Signal Dispatcher" daemon prio=10 tid=0x008BA460 nid=0x1b8 waiting on 
condition [0..0]

"Finalizer" daemon prio=9 tid=0x009006D0 nid=0x7ec in Object.wait() 
[165ff000..165ffd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <03D20138> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <03D20138> (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=0x008E5AB0 nid=0x7d4 in Object.wait() 
[165bf000..165bfd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <03D201A0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:426)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113)
        - locked <03D201A0> (a java.lang.ref.Reference$Lock)

"main" prio=5 tid=0x00235528 nid=0x7d0 runnable [6f000..6fc40]
        at org.eclipse.jdt.core.JavaConventions.scannedIdentifier
(JavaConventions.java:87)
        - waiting to lock <134F3190> (a java.lang.Class)
        at org.eclipse.jdt.core.JavaConventions.validateIdentifier
(JavaConventions.java:221)
        at org.eclipse.jdt.internal.core.Util.isValidFolderNameForPackage
(Util.java:947)
        at org.eclipse.jdt.internal.core.Util.packageName(Util.java:1138)
        at org.eclipse.jdt.internal.core.JavaModelManager.determineIfOnClasspath
(JavaModelManager.java:409)
        at 
org.eclipse.jdt.internal.core.JavaModelManager.createCompilationUnitFrom
(JavaModelManager.java:331)
        at org.eclipse.jdt.internal.core.JavaModelManager.create
(JavaModelManager.java:261)
        at org.eclipse.jdt.internal.core.JavaModelManager.create
(JavaModelManager.java:225)
        at org.eclipse.jdt.core.JavaCore.create(JavaCore.java:1003)
        at org.eclipse.jdt.core.JavaCore.create(JavaCore.java:971)
        at org.eclipse.jdt.internal.ui.JavaElementContainmentAdapter.contains
(JavaElementContainmentAdapter.java:43)
        at org.eclipse.ui.views.markers.internal.MarkerFilter.isEnclosed
(MarkerFilter.java:215)
        at org.eclipse.ui.views.markers.internal.MarkerFilter.selectBySelection
(MarkerFilter.java:157)
        at org.eclipse.ui.views.markers.internal.MarkerFilter.select
(MarkerFilter.java:119)
        at org.eclipse.ui.views.markers.internal.ProblemFilter.select
(ProblemFilter.java:44)
        at org.eclipse.ui.views.markers.internal.MarkerFilter.filter
(MarkerFilter.java:103)
        at org.eclipse.ui.views.markers.internal.MarkerRegistry.getElements
(MarkerRegistry.java:58)
        at org.eclipse.ui.views.markers.internal.MarkerRegistry.getItemCount
(MarkerRegistry.java:254)
        at org.eclipse.ui.views.markers.internal.MarkerView.updateTitle
(MarkerView.java:534)
        at org.eclipse.ui.views.markers.internal.MarkerView$5.run
(MarkerView.java:461)
        at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
        at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages
(Synchronizer.java:102)
        - locked <03170468> (a org.eclipse.swt.widgets.RunnableLock)
        at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2150)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1867)
        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=0x008E5148 nid=0x65c runnable

"VM Periodic Task Thread" prio=10 tid=0x00900998 nid=0x854 waiting on condition
Comment 2 Jerome Lanneluc CLA 2003-10-02 11:46:32 EDT 
According to the trace, time is spent in the Task and Problem view, not in the 
Debugger. This should be moved back to Platform/UI.
Comment 3 Darin Swanson CLA 2003-10-02 12:24:20 EDT 
Your wish is my command...
Comment 4 Frederic Fusier CLA 2003-10-03 05:36:01 EDT 
I confirm that's it's not related with debugger but with Problems view as I 
have also noticed long response time while editing a class: when I select a 
block of code using the mouse, it takes 2 or 3 seconds before the block is 
actually selected in the editor.

When I close the Problems view this long time response disappear. But instead 
of what I'm saying when I opened the bug, it seems to be related to the filter. 
I have reopned the Problems view and noticed that I still had a filter in it... 
I remove the filter and then response time back normal again :))

Hope this further information will help to find out what happen here...
Comment 5 Debbie Wilson CLA 2003-10-07 11:22:42 EDT 
*** Bug 44294 has been marked as a duplicate of this bug. ***
Comment 6 Debbie Wilson CLA 2003-10-07 11:24:23 EDT 
Info from Kent J. - this is a new behaviour for the Problems View as of build 
I20030930.

Changing the priority as this is a new behaviour.
Comment 7 Frederic Fusier CLA 2003-10-07 12:19:46 EDT 
Additional information:
It seems that this is only the 'On Working Set' option which causes some 
troubles. When one of the other 'On...' options is selected I didn't get any 
slow response time in my workspace...
Comment 8 Debbie Wilson CLA 2003-10-07 12:39:40 EDT 
Created attachment 6350 [details]
Jar file for org.eclipse.ui.views

Can you try working with the attached jar file to see if this solves your
problem?  Have pulled a fix and put us back to pre-0930 state.	This jar is
based on an environment built with 1007.
Comment 9 Debbie Wilson CLA 2003-10-07 14:02:50 EDT 
Bug 44294 suggested using a post selection change listener.  This does not 
solve the problem.

Retracted fix for bug 39436.  This seems to fix the problem.  Will leave it in 
this state for M4.
Comment 10 Debbie Wilson CLA 2003-10-07 15:05:27 EDT 
Fixed post I20031007
Comment 11 John Arthorne CLA 2003-10-07 19:17:49 EDT 
See also bug 43721 where a user is reporting extreme performance problems on
Mac... he reported that turning off the marker view filtering fixed his problem.
Comment 12 Frederic Fusier CLA 2003-10-08 07:13:08 EDT 
Debbie,
Do you still want me to test the fix in attached jar file or only test with 
build I20031008 which will be done today?
Comment 13 Debbie Wilson CLA 2003-10-08 09:36:06 EDT 
Just test with I20031008.  Thanks.
Comment 14 Debbie Wilson CLA 2003-10-09 10:20:30 EDT 
Verfied in I20031008 (15:56 version).
Comment 15 Frederic Fusier CLA 2003-10-09 10:31:04 EDT 
I agree
Comment 16 John Arthorne CLA 2003-10-09 14:05:35 EDT 
Kent is reporting that this is not fixed in 20031008H1556 when markers view is
filtered on a working set.

Incremental build is taking several seconds when filtering on working set, and
is instantaneous when filtering is turned off
Comment 17 John Arthorne CLA 2003-10-09 14:18:56 EDT 
This is probably actually a dup of bug 42923 and bug 44443.
Comment 18 Debbie Wilson CLA 2003-10-11 07:07:00 EDT 
Am re-resolving this report to eliminate some confusion.

The problem originally reported here is, in fact, fixed.
There is, however, another performance issue with filtering on a Problems view 
addressed in bug 44443 (filtering not very efficient).  This is the problem 
which Kent is now noticing.  The problem in 44443 has been around since 
3.0M1.  I have up-ed its priority to P2.

Please add your name to the CC list of bug 44443 if you are interested in this 
issue.
Comment 19 Debbie Wilson CLA 2004-02-10 14:49:17 EST 
Verified in I20040210 (8:00 am) - M7 candidate.