Bug 71166 - Slow switching between compilation unit editors in the debug view
Summary: Slow switching between compilation unit editors in the debug view
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: 3.1   Edit
Assignee: JDT-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2004-07-30 12:01 EDT by Ed Burnette CLA
Modified: 2005-04-01 18:05 EST (History)
0 users

See Also:


Attachments
Compressed .cpu sample from YourKit 3.0 eap build 401 (348.44 KB, application/x-zip-compressed)
2004-07-30 12:03 EDT, Ed Burnette CLA
no flags Details
Updated compressed .cpu trace file (813.71 KB, application/zip)
2004-12-16 13:07 EST, Ed Burnette CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Burnette CLA 2004-07-30 12:01:17 EDT
I'm stopped at a breakpoint and click on a stack frame to edit its source 
code. Then I click on another stack frame and there is a noticable pause 
before I can see that code. Click on the first one again, noticable pause. I 
profiled this and most of the time is spent under the routines 
CompilationUnit.becomeWorkingCopy and CompilationUnit.discardWorkingCopy. See 
the attached output from Yourkit for details.

The two java source files I'm switching between are 2792 and 251 lines long, 
respectively (BuiltinFunTable and FunCall from mondrian sourceforge project if 
it matters). Both are in my workspace (not being pulled from Jars). They are 
not dirty. I have advanced formatting and annotations turned on but the 
tracebacks are not implicating those that I can see. I notice some slowness 
with other files but this is the only case I looked at in detail. JVM mem size 
is set to 256MB.
Comment 1 Ed Burnette CLA 2004-07-30 12:03:55 EDT
Created attachment 13689 [details]
Compressed .cpu sample from YourKit 3.0 eap build 401

To get this I turned on sampling and switched back and forth between the two
files a few times in the debug view, then turned off sampling. I did NOT have
the outline view open.
Comment 2 Kent Johnson CLA 2004-08-03 10:19:03 EDT
Do you get similar behaviour outside of the debugger (ie. in the Java 
perspective) with the same 2 files?
Comment 3 Jerome Lanneluc CLA 2004-12-16 06:47:08 EST
According to the attached cpu sample, 49% of the time is spent in
og.eclipse.debug.internal.core.OutputStreamMonitor$1.run(). Only 4% of the time
is spent in becomeWorkingCopy.
Moving to JDT Debug for comment.
Comment 4 Kevin Barnes CLA 2004-12-16 12:04:12 EST
OutputStreamMonitor has undergone significant changes as part of the console reworking in 3.1. Is this 
still an issue?
Comment 5 Ed Burnette CLA 2004-12-16 13:07:37 EST
Created attachment 16707 [details]
Updated compressed .cpu trace file

I still see slowness here. I captured a new cpu log with YourKit3.2, Method
tracing enabled, JDK5, and the I20041214-2000 build of Eclipse 3.1.
Comment 6 Ed Burnette CLA 2004-12-16 13:10:50 EST
Re comment #2: No, if both files are open side-by-side I don't get any slowness
in any case. It's only if there is one editor window and I'm in the debug view
and the IDE is swapping the contents of the editor window for another file
because I clicked on the stack trace.
Comment 7 Darin Wright CLA 2004-12-17 13:50:35 EST
Sorry, I only have version 2.5.2 of yourkit. Does the trace look like a 
problem with the debugger, or a problem with the editor framework for 
resetting the input?
Comment 8 Kevin Barnes CLA 2005-04-01 18:05:23 EST
Not seeing the slowness. Marking as WORKSFORME