Community
Participate
Working Groups
This may relate to bug#108960, but I create a separate bug anyway. We've had this problem in Eclipse 3.1.1 for a while and now I think I found the reason for it. When an application uses exceptions for program flow control, debugging becomes extremely slow. Of course, such programming is bad practise, but at least javacc seems to generate code that does it. I get this problem constantly. I'm running Eclipse with jre1.5.0_05 on Windows XP. My colleaque runs Eclipse 3.1.0 on an identical computer with jre1.5.0_02 and he doesn't get it always. I had the same problem also 3.1.0. Here's a trivial program that can be used to duplicate the problem: public class DebugTest { static Exception ex = new Exception() { private static final long serialVersionUID = 1L; }; public static void main(String[] args) { long time = System.currentTimeMillis(); for (int i = 0; i < 1000000; i++) { try { throwException(true); } catch (Exception e) { // do nothing } } System.out.println("Elapsed time = " + (System.currentTimeMillis() - time)); } private static boolean throwException(boolean foobar) throws Exception { if(foobar) { throw ex; } return false; } } When I run the program, elapsed time is 156 ms. When I debug it (without breakpoints), elapsed time is 18968 ms. The "Suspend execution on uncaught exceptions" option has very little effect. I hope you can get this duplicated and fixed. Pasi
Turn off both options to susupend on uncaught exceptions and compilation errors. When I do this the run/debug times are the same.
We have improved the performance of the compilation error handling. See bug 108473. However, the difference between run and debug is still large. Needs more investigation. Marking as 3.1.2 candidate.
I still have difference between run/debug times. The debug time is 4797 and run time 265 after I've turned off these both options. Is bug#108474 fixed in 3.2M2?
I also see different run times. However, the difference does seem to depend on which machine I use (laptop vs. hyper threaded workstatino). Yes, the fix to bug 108473 is in 3.2M2. This bug is assigned for more investigation to see if we can reduce the difference more.
I run on hyper-threaded workstation. I thought that throwing java.lang.Error would behave differently to Exception as suggested in bug 108473, so I modified the test program slightly, but the times didn't change. This is the modified code, if it helps: public class DebugTest { static Throwable ex = new Error() { private static final long serialVersionUID = 1L; }; public static void main(String[] args) { long time = System.currentTimeMillis(); for (int i = 0; i < 1000000; i++) { try { throwException(true); } catch (Throwable e) { // do nothing } } System.out.println("Elapsed time = " + (System.currentTimeMillis() - time)); } private static boolean throwException(boolean foobar) throws Throwable { if(foobar) { throw ex; } return false; } }
moving to 3.2
I took the test case and ran it from the commandline in debug mode and noticed the the VM by itself causes over 6000ms of work with no external interaction. If we then consider Eclipse interacting with the VM in debug mode, to achieve times of approx. 18000ms, I would say this is more of a VM problem than an Eclipse one. I will post an attachment to show the profile of running eclispe in debug mode and the amount work it does on our end, which turns out to be approx. 170ms.
Created attachment 38305 [details] profile The profile of the total amount of work eclipse does concerning the treatment of exceptions.
closing as WORKSFORME, if any other issues come up, please reopen so we can investigate.
