History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: IDEA-11775
Type: Performance Problem Performance Problem
Status: Open Open
Assignee: Alexey Kudravtsev
Reporter: Bas Leijdekkers
Votes: 5
Watchers: 7
Operations

If you were logged in you would be able to see more operations.
IDEA: Feedback

Java editing is slow

Created: 02 Mar 07 17:08   Updated: 25 Apr 07 17:51
Component/s: Editor. Editing Text

File Attachments: 1. Zip Archive 6737_Eigenaar_02.03.2007_15.32.52.zip (2.88 Mb)
2. Zip Archive 6808_Bas_10.04.2007_17.08.26.zip (3.17 Mb)
3. Zip Archive 6808_simonk_11.04.2007_12.55.37.zip (3.71 Mb)
4. Zip Archive 6913_taras_18.04.2007_16.10.40.zip (3.19 Mb)
5. Zip Archive 6913_taras_18.04.2007_16.18.35.zip (3.21 Mb)


Build: 6,737
Severity: High


 Description  « Hide
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.

 All   Comments   Work Log   Change History      Sort Order:
Bas Leijdekkers - 02 Mar 07 17:33
Some editing with Hector set on Syntax only. Let me know if you need any more.

Sascha Weinreuter - 02 Mar 07 17:38
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 - 02 Mar 07 17:59
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 - 10 Apr 07 19:21
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 - 10 Apr 07 23:19
Bas,
in your case the problem seems to be in open project view

Bas Leijdekkers - 11 Apr 07 10:06
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 - 11 Apr 07 14:21
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 - 11 Apr 07 14:41
another 2 secs are in PsiClass.isInterface() and PsiClass.isAnnotationType() that not cached too, delegating to the repository.

Simon Knott - 11 Apr 07 16:04
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 - 11 Apr 07 16:19
Sorry I should add that the inspections I'm talking about are the in-editor inspections highlighting, not the manually triggered inspections.

Taras Tielkes - 18 Apr 07 18:11
Attached two short-duration CPU snapshots captured during (slow) editing. 4 projects were open.

Alexey Kudravtsev - 25 Apr 07 17:51
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.