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

Bug 293657

Summary:	[breakpoints] It takes a long time to toggle a breakpoint
Product:	[Eclipse Project] JDT	Reporter:	Frederic Fusier <frederic_fusier>
Component:	Debug	Assignee:	JDT-Debug-Inbox <jdt-debug-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	major
Priority:	P3	CC:	darin.eclipse, Michael_Rennie
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Frederic Fusier

2009-10-29 07:45:49 EDT

3.6M3 candidate but I already notice this issue since a little while...

I'm annoyed by the long time response while toggling breakpoint. E.g. while adding/removing a breakpoint in the org.eclipse.jdt.internal.formatter.Scribe class. This is not a huge compilation unit, currently 162,446  bytes, hence I wonder why it takes around 3 seconds to set a breakpoint and around 2 seconds to remove it? Is it related to the current issue or should I open a new bug for this?

This is really annoying while as I frequently change breakpoints places. Note that it may sometimes last longer than that (I already measures 10 seconds before the new breakpoint status appears in the editor!) and sometimes with temporary UI freeze (ie. the entire window becomes blank for a few seconds).

Note also that doing the same operation is instantaneous when using 3.5 (e.g. M20090930-0825). So it looks like a performance regression, hence I set the severity as major

Comment 1 Frederic Fusier

2009-10-29 07:47:48 EDT

(In reply to comment #0)
> Is it related to the current issue or should I open a new bug for this?
> 
Forgot this sentence, I initially wrote the comment in bug 286938 and finally decide that it was better to directly open a new bug...

Comment 2 Darin Wright

2009-10-29 09:18:23 EDT

Mike, can you investigate?

Comment 3 Michael Rennie

2009-10-29 11:19:41 EDT

Still waiting on the performance tests (locally), but it does seem a bit sluggish toggling a breakpoint in the Scribe class Frederic mentioned.

The only fixes that have gone into Debug for breakpoints that would affect toggling are:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=208744
and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=223315

the second bug makes use of ITypeBindings but cuts down the number of ASTs we used to create by a factor of 4 for line breakpoints (used to create 4 now it only creates 1).

investigating...

Comment 4 Frederic Fusier

2009-10-29 12:25:53 EDT

Note that it does not looks related to this specific CU as I also get the same problem with any other smaller or bigger JDT/Core classes, e.g.:
 - org.eclipse.jdt.core.tests.formatter.FormatterMassiveRegressionTests
   -> 44,805 bytes: approx. same times than Scribe to set/unset bkp
 - org.eclipse.jdt.internal.compiler.parser.Parser
   -> 410,053  bytes: approx. double times than Scribe to set/unset bkp

On all tests I did, it seems that the time does not depend on the bkp position (ie. it's the same setting/unsetting bkp at the beginning or at the end of the CU).

Comment 5 Frederic Fusier

2009-10-29 12:29:27 EDT

One more piece of information, I tried with the largest file we have in JDT/Core: org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest which is 1,732,826  bytes long and it takes the same time than for Scribe. That would mean this time was more dependent on the nodes numbers (or nodes hierarchy complexity) rather than pure file length...

HTH

Comment 6 Eclipse Genie

2019-09-28 19:04:41 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.