Priority
Normal
Type
Performance Problem 
State
Obsolete 
Assignee
Alexey Kudravtsev 
Subsystem
Editor. Editing Text 
Affected versions
Fixed in
Fixed in build
Next build 
Build
6737
Severity
0
  • Submitted by   Bas Leijdekkers
    2 years ago (02 Mar 2007 17:08)
  • Updated by   Dmitry Jemerov
    2 months ago (04 Dec 2009 19:21)
  • Jira: IDEA-11775
    (history, comments)

IDEA-11775

Java editing is slow
7
6913_taras_18.04.2007_16.18.35.zip   (3 MB) 6913_taras_18.04.2007_16.10.40.zip   (3 MB) 6808_simonk_11.04.2007_12.55.37.zip   (3 MB) 6808_Bas_10.04.2007_17.08.26.zip   (3 MB) 6737_Eigenaar_02.03.2007_15.32.52.zip   (2 MB)
For the a while now (at least since build #6708) editing java code is really slow. IDEA cannot keep up with my typing and maxes out the cpu. Opening more than one project seems to exacerbate the problem, making IDEA completely unusable for java code editing.
Instructing Hector to use highlighting level none fixes the issue. Only using syntax highlighting and not inspections does not help, so the problem seems to be related to syntax highlighting.
The problem is especially bad on a single core cpu machine. On a multi core machine it is less noticeable, perhaps because such a machine can spend one core on syntax highlighting and then have a core left to handle the users editing. Opening more than one project kills that advantage too however.
I will attach one or more cpu snapshots in a moment.
Comments (13)
 
History (1)
 
Links
  
Bas Leijdekkers
  Bas Leijdekkers
02 Mar 2007 17:33
(2 years ago)
#permalink
Some editing with Hector set on Syntax only. Let me know if you need any more.
Sascha Weinreuter
  Sascha Weinreuter
02 Mar 2007 17:38
(2 years ago)
#permalink
Hmm, I noticed something similar, though I think it's actually worse on my new dual core machine now than it was before - but that could be a coincidence with some changes in IDEA. My basic theory is that either IDEA does not (enough) reduce the priority of the parsing/highlighting threads and/or should not use all available cores for the highlighting to keep a spare one that allows the rest of the IDE to stay responsive.

An easy, preliminary solution might be to introduce a system-property that says how many cores IDEA should use, instead of using Runtime.getAvailableProcessors()
Bas Leijdekkers
  Bas Leijdekkers
02 Mar 2007 17:59
(2 years ago)
#permalink
My theory is that idea suffers from two problems:
  • It now uses too coarse grained locking on the highlighting thread, which leads to starvation of the editing thread.
  • Performance gets much worse when opening more than one project. That seems like a plain bug to me.

We could both be right:-)
Bas Leijdekkers
  Bas Leijdekkers
10 Apr 2007 19:21
(2 years ago)
#permalink
Snapshot of typing with two projects open. After typing something in one project, both projects were analyzed (judging by the little square in the top right of the editor).
Mike Aizatsky
  Mike Aizatsky
10 Apr 2007 23:19
(2 years ago)
#permalink
Bas,
in your case the problem seems to be in open project view :(
Bas Leijdekkers
  Bas Leijdekkers
11 Apr 2007 10:06
(2 years ago)
#permalink
Mike,
It does seem that way, but I am not doing anything with the project view. Why does it have to use so much cpu? And why does it use twice as much cpu when I have two projects open? But at least I have a workaround now, closing the project pane seems to alleviate the problem a bit.
Thanks for looking into it.
Dmitry Avdeev
  Dmitry Avdeev
11 Apr 2007 14:21
(2 years ago)
#permalink
btw I see 2 seconds in com.intellij.openapi.vfs.impl.local.VirtualFileImpl.getPhysicalFileLength() that is not cached, but delegates to file system
Dmitry Avdeev
  Dmitry Avdeev
11 Apr 2007 14:41
(2 years ago)
#permalink
another 2 secs are in PsiClass.isInterface() and PsiClass.isAnnotationType() that not cached too, delegating to the repository.
Simon Knott
  Simon Knott
11 Apr 2007 16:04
(2 years ago)
#permalink
I'm getting horrendous slow-downs as well when inspections are in progress (see attached CPU snapshot). I'm on a dual-core machine and the CPU is completely maxed out when the inspections are happening - for example, the class that was being inspected for the snapshot takes almost 30 seconds to finish processing and in that time the IDE was really unresponsive.

One thing I have just noticed is that if you have the IDE in a split configuration, ie. two sets of tab groups, certain things like "Reformat Code" occasionally trigger inspections in both editor panes. Obviously one of the editor panes won't have changed, so I'm not quite sure why it's being re-inspected.
Simon Knott
  Simon Knott
11 Apr 2007 16:19
(2 years ago)
#permalink
Sorry I should add that the inspections I'm talking about are the in-editor inspections highlighting, not the manually triggered inspections.
Taras Tielkes
  Taras Tielkes
18 Apr 2007 18:11
(2 years ago)
#permalink
Attached two short-duration CPU snapshots captured during (slow) editing. 4 projects were open.
Alexey Kudravtsev
  Alexey Kudravtsev
25 Apr 2007 17:51
(2 years ago)
#permalink
Taras, these snaphots you've attached show it is Project View|Packages update that causes slowness. Closing Project View(or switching from Packages View to Project) can help.
Dmitry Jemerov
  Dmitry Jemerov
04 Dec 2009 19:21
(2 months ago)
#permalink
We've made a ton of fixes since IDEA 7, which is when the snapshots were captured. If you still see problems in IDEA 9, please file new issues with snapshots attached.