Community
Participate
Working Groups
I am debugging a very large application based on the WSW platform. It has about 275 plugins. If I try to add a breakpoint to the code while the platform is running (in debug mode) it takes about 20 s for the breakpoint to appear after I double click on the marker bar. The debug source is part of a project within my workspace. Perhaps I should go for a coffee while I set my breakpoint.
Need more info: What version of Eclipse? What VM are you using (i.e. what VM are you running Eclipse on)? Do you have any programs running when setting the breakpoints?
I am running F3 C:\WINNT\system32>java -version java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cn130-20010502 (JIT enabled: jitc) ) At the time I probably had Lotus Notes and Sametime running. I may have also had Netscape Composer / Navigator running.
deferred for post 2.0 investigation.
re-open to close
Uable to reproduce
I'd like to comment that this is still pretty bad under my environment, but not 20's, more like 2 seconds, but the lag is sufficient to wonder what's going on, perhaps the break point wasn't set, so you double click again. Quite frustrating. Happens on my environment under Sun JDK1.4.0 and Sun JDK1.4.2, running on Windows 2k, with PIII 1.7 Ghz, 1 Gb RAM.
Paul, can you provide a test case - i.e. the compilation unit where you are setting the breakpoint?
[This next comment was accidently posted to an incorrect bug, pasting into correct Bug report] Hi Darin, I created a brand new project, with a single class in it, and while in the Java Browsing perspective, setting break points is fine with a single class in the project. Even debugging this basic project is snappy setting/removing the break points. However, with two other projects which have 1,400 and ~1000 source files in them, the snappiness is gone. Seems to be related to the size of the project? I could attach one the projects as an entire directory to this bug if it would work for you (this is the jakarta-log4j module that I am working on so it's Open Source), the other project is proprietary and I couldn't provide that. I think you also responded to Bug #20487 regarding Content assist, and I'm thinking this is also related to the size of the debugging project. Both projects use the same VM, Sun JDK 1.4.2. Just changed to this new VM recently, but we were using Sun JDK 1.4.0 for many months with the same problems.
