Bug 27321

Summary:

hovering allocates megabytes in seconds

Product:

[Eclipse Project] JDT

Reporter:

Adam Kiezun <akiezun>

Component:

Text

Assignee:

JDT-Text-Inbox <jdt-text-inbox>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

philippe_mulet

Version:

2.1

Keywords:

performance

Target Milestone:

---

Hardware:

OS:

Windows 2000

Whiteboard:

Attachments:

Description	Flags
118 megabytes allocated by 5 seconds of hovering	none

Description Adam Kiezun

2002-11-28 10:02:47 EST

moving the mouse cursor over in java editor, you want it or not - allocates 
megabytes of memory in a couple of seconds.
mostly codeSelect

entering the bug here - unsure if ui or core problem

Comment 1 Adam Kiezun

2002-11-28 10:03:32 EST

Created attachment 2565 [details]
118 megabytes allocated by 5 seconds of hovering

Comment 2 Adam Kiezun

2002-11-28 10:03:55 EST

i meant 18, not 118

Comment 3 Adam Kiezun

2002-12-09 09:11:42 EST

97% caused by codeSelect

Comment 4 Philipe Mulet

2002-12-09 10:43:37 EST

Again, this is a consequence of some eager activation from JDT/UI side.

Comment 5 Adam Kiezun

2002-12-09 11:43:51 EST

please clarify what you mean by 'eagerly activate'
when you hover, we call codeSelect - which allocates all this memory
what can we do differently?

Comment 6 Philipe Mulet

2002-12-10 04:39:45 EST

CodeSelect isn't a free operation, if UI activates it too often, when there is 
no actual expectation from a user (i.e. while cursor is still moving) then it 
is pointless.

Comment 7 Adam Kiezun

2002-12-10 04:42:27 EST

moving to text for comment and further action.
can codeSelect be called less often on hovering?

Comment 8 Kai-Uwe Maetzel

2002-12-10 12:05:44 EST

The call of codeSelect is result of the SWT mouse hover event. Currently, there 
is not way to change its timing. The computation of the hover info, i.e. the 
call of codeSelect, is performed in a background thread. If the mouse moves on 
while this background thread is active, it would be useful to cancel the 
thread. Most of the time is spent in codeSelect. Thus, having codeSelect 
cancelable would be useful because it would ensure that at most one computation 
is running at any time.

Comment 9 Kai-Uwe Maetzel

2003-01-28 11:47:45 EST

Haven seen any reaction from core.