General Sluggish-ness

Thanks for the report. I'll try to improve performance soon. In your case SOE can be sluggish-ness problem (additionally to stack overflow, resolve cache not work when SOE detected).

Best regards,
Alexander Podkhalyuzin.

I also noticed this today, with the nighly build scala+intellij is just unusable.  CPU will spike to > 500%, and it can take 10 seconds for single keystrokes to register.  Extremely painful.  I feel like I'm on Eclipse circa 2005 again.

I'm reverting to the last released scala plugin because of the slowness.  When I can't type properly, it is no good.  It appears to be the plugin doing "background" compilation.

Oh yes, and this is on a i7 mac pro with 12gb ram.

I think different code styles/projects could involve different performance hotspots in the plugin.
Obtaining a CPU snapshot for your specific case is easy, and greatly increases the chances the see a fix.

-tt

I downgraded the Scala plugin release-by-release back to 0.4.833 and tested the same keystrokes in the same project with each (typed an object name followed by the first letter of a method on that object). 0.4.833 is the last release that works well on my machine with IDEA 107.148. So, the issue was introduced somewhere between the 0.4.833 and 0.4.1041 builds. Hope this helps.

I'm also having a painfully slow coding experience with
- Scala plugin 0.4.1084
- IDEA build  #IU-107.105

It would be nice if there was a checkbox somewhere called "Last Resort / Remove All IDE fancyness",
when checked, would disable every feature that can possibly slow down code editing...

Max

I'm using IU-107.105 with nightly build 1116.  Very slow!

Today autocomplete stopped working.  Autocompleteing variable names?  Big pause, empty dropdown box appears, it eventually populates.  Similarly, waiting for Idea to find and suggest a reasonable import takes forever.

Meanwhile, auto-import is so lightning fast that when I try to type _ in a closure it cheerfully autocompletes with _RMIConnectionStub or _jsp blah etc etc before I can get to the period key.

I'm hitting the eject button here and reverting back a couple of weeks in the builds.

Yes having _ autocomplete to unrelated (and obsolete!) java technology internal implementation is... annoying in the least.  Also having 'val' autocomplete to 'Value' is equally silly.  

One thing I noticed on the slowness, is it was slower when i was backspacing than typing.  Clearly the internal scala parser is working overtime.

Eventually settled back with nightly build 1031 - autocomplete is very noticeably slow, but better than 1116.

Even typing the name of a class that has already been imported causes a big ugly pause where keyboard input lags.

I have to agree as well. I tried 10.5 for a day, tried some nightly builds. Nothing allows me actually to get real work done. So I'm going back to a previous version of IntelliJ, or back to Emacs + Ensime.

I've registerd into this forum just to say that I agree, 10.5 with scala is unusable... I've reverted to 10.4 for the time being. I hope it will become usable at some point...

best,
Miguel Negrão

Using idea-IU-107.199 with nightly build 0.4.1125.

Performance is very bad, functionality works less well than in the 10xx series in some regards:

• my quadcore i7 is constantly pegged on all four CPUs.  Restarting helps temporarily, but once it's been like this for a while, all you can hope to do is exit cleanly so you don't corrupt your indices or risk losing work
• syntax hightlighting is very far behind the spot where I am typing (to the point where I write a spec, run it several times, and finish it before syntax highlighting catches up)
  
• mouse pointer gets stuck on "hand" when I hit CTRL to CTRL click something
• when I type in a new class name, it can take up to thirty seconds to suggest an import
  • weirdly, though, when I am trying to type inside a closure, auto-import  responds like a meth-crazed mink by importing any class that begins with  the _ character before I can type a period (although, thanks, I think  my auto-import blacklist is finally seeded to a good place via this exercise,  so there is a bright side)
    
  • for some reason, when I type SortedMap, the first suggestion is java.util.SortedMap (why would this be the first choice when writing Scala?), followed by, ten seconds later, scala.collection.SortedMap, followed, finally, usually just as I am heading to the imports section to type it in myself, it sheepishly pops up with scala.collection.immutable.SortedMap
• Given the speed that closures autocomplete to a random class beginning with _, it is particularly galling that the ctrl+spacebar autocomplete dropdown is unbelievably slow, frequently freezing the entire editor before finally popping up blank and hanging there empty for a few seconds
• when I attempt to click into source code sometimes Idea goes to the class in the jar even when the source jar shows up in the module lib def - minor, although highly irksome
• "suspicious shadowing" - must look for a way to turn off this inspection, as I was doing that on purpose :p

I really appreciate the new functionality, but unfortunately, I must be able to type in an editor that at least display each letter as I type it, and doesn't freeze for several seconds every time I copy and paste a variable name (which I wouldn't do if autocomplete worked anyway).

Is there something I'm missing here?  I have been monitoring Idea's  memory
usage, but it's been quite reasonable (this behaviour is totally unlike the baroque memory spikes of some of the 0.4.09xx builds).  I don't think Idea is  stressed for memory, nor for disk speed (using an SSD, set inotify.max_user_watches to 524288 as recommended),  but this type of sustained CPU usage just seems wrong.

I'd revert back to last stable, but I have been flipping through my rolodex of nightly builds and frankly haven't found one lately that is much better than this.

Hi, what is the least unstable combination of version (of IDEA and Scala plugin) for a project that requires 2.9.0-1 ?

Possible sluggish-ness causes are autopopup completion.
In this case there are few solutions.
1. Please try IDEA 10.5 EAP 107.199 build. Possible completion performance problem fixed in this build.
2. If it's not help, try to disable autopopup completion.
3. If typing is still bad, then please send be another snapshot (without autopopup completion).

According to your snapshot your problem is completion, but I'm not sure.
Also we'll make few general optimizations soon.
Sorry for so big delay before I answered.

Best regards,
Alexander Podkhalyuzin.

I was noticing yesterday, telecommuting and using my home computer (2
core, 2GB RAM) that it did get very sluggish after a while - using 107.199.

On my office computer (8 core, 8GB RAM) it seems fine.

On 6/14/11 4:56 PM, Alexander Podkhalyuzin wrote:

Possible sluggish-ness causes are autopopup completion.
In this case there are few solutions.
1. Please try IDEA 10.5 EAP 107.199 build. Possible completion performance problem fixed in this build.
2. If it's not help, try to disable autopopup completion.
3. If typing is still bad, then please send be another snapshot (without autopopup completion).

>

According to your snapshot your problem is completion, but I'm not sure.
Also we'll make few general optimizations soon.
Sorry for so big delay before I answered.

Thanks, Alexander, using 107.199 with nightly build 1126 was something of an improvement.

Editor performance is a little better (and less aggressive with my CPU) but the following problems remain:

• autocomplete is slow, unhelpful, occasionally infuriating
  
  • autocompleting the name of a field or a method on a class still sluggish
    
  • somehow though, auto-complete instantly attempts to transform scala keywords such as "def" or "val" into useless class imports or implicit method names: this happens when you are supplying params to a closure or going back to convert a val into lazy val or turn a val into a def
  • ... aggressively expands params I am passing in to the closure to be the names of implicit methods instead
  • Scala annotation @override is forcibly converted to Java @Override annotation as I type (silently taking out the "val" after it, too)
• auto-import is slow, unhelpful,  infuriating
  • when I type in the camel-case letters of a class name and hit ctrl+space, the editor obstinately refuses to import anything
  • when I type in the full name of the class, Idea highlights it red for a while, and after a long pause then offers a bunch of useless optiopns to create anonymous classes or methods with my class name, and then finally, when I got back into the suggestions a second time, offers the ability to import my class as the next to last (?!) suggestion
  • auto-import does not respect the Scala convention of using Imports._ - if there is a type class called Foo in baz.Imports._, then my imports list will eventually contain both "import baz.Imports._" and "import baz.concrete.whatever.Foo".
  • within a closure, auto-import is lightning fast and unbelivably annoying: _ completes to a variety of dead Java technology that I never even knew existed until very recently - sun.java2d :)
    

The autocomplete problems (so unbelievably slow!) and auto-import problem (glacial, unless undesired, in which case it autocompletes instantly and aggressively) remain.

Still rather bad on my quadcore laptop, but acceptable on my octocore box at work.

This has really been an adventure - trying out 1130 right now!

Hi Alexander,

Is there anything I can do (in settings or whatever) to speed up the syntax checker's response time? Besides what already has been said, that's my biggest issue with the plugin (right now it takes 4-10 sec to have an update on syntax errors, so many times it's actually faster to use sbt's ~compile feature)

Thanks in advance!

os x 10.6.7
jvm 1.6.0_24
idea 107.199
scala plugin 1127

To gain more speed you may do the following:

• Close Structure view
• Turn off "Show members" in project view
• Disable IDE Settings / Code Completion / Autopopup code completion
• Turn on Project Settings / Code Style / Scala / Other settings / Disable parsing of documentation comments
• Turn on Project Settings / Code Style / Scala / Other settings / Disable injection in Scala files (or disable IntelliLang plugin)

one of my biggest problems is working with tuples. typing things like "_._2" turns into _rmi_whatever_funky_class and one letter parameters turn into random class names:
List(1,2,3,4) foreach (e => ...)

the "e" becomes "Exception" or something else beginning with "e"

Try seeding your auto-import blacklist to get rid of the main sources of spurious imports from weird old packages you never use -

Close Idea, go to config/options/editor.codeinsight.xml -look for "EXCLUDED_PACKAGE" and add away - these helped to reduce my _ junk autocompletes, only see really strange stuff occasionally now :) - then reopen Idea.  You can edit this though IDE Settings by going to Editor | Auto Import but if you are adding a bunch of packages it's more convenient to just stock the XML file:

    <EXCLUDED_PACKAGE NAME="com.sun.corba" />
    <EXCLUDED_PACKAGE NAME="com.sun.org" />
    <EXCLUDED_PACKAGE NAME="org.omg" />
    <EXCLUDED_PACKAGE NAME="java.rmi" />
    <EXCLUDED_PACKAGE NAME="javax.swing" />
    <EXCLUDED_PACKAGE NAME="javax.management" />
    <EXCLUDED_PACKAGE NAME="com.sun.xml" />
    <EXCLUDED_PACKAGE NAME="javax.xml.soap" />
    <EXCLUDED_PACKAGE NAME="sun.java2d" />
    <EXCLUDED_PACKAGE NAME="org.specs2.internal.scalaz.Digit._0" />


Alas, this doesn't fix your params being expanded into weird class names or heretofore unknown implicits.

Pavel, I tried all your suggestions (except the last one - I couldn't see this option) to no avail.

For me, the problem is only when editing long files, say over 150 lines. The CPU load maxes out, while I'm doing something as simple as typing "System.out.print" (for want of a better example) and when trying to delete it with backspace, or adding a new line with carriage return. When doing the same on a short file (say 20 lines) the editor is perfectly useable and responsive.

There seems to be something fundamentally broken in the editor as it is at the moment. Just typing something simple should not require 100% CPU. It should not even require 10% CPU. And even if there is some intensive work going on in the background, it should be designed so that it would never impact the user. I haven't used IDEA much so I don't know whether it's always been like this or not.

I've had to go back to Eclipse because of this issue, which is unfortunate since some things about IDEA are much better - the code completion and Scaladoc integration, for example.

Is there a ticket for this in your database?

Have you tried increasing the amount of memory available to idea. I find this helps in certain circumstances.

Go to idea.vmoptions in the bin directory (on linux) and change the -Xmx flag to:

-Xmx1024m

This has helped me in the past.

Yes, memory is very important for Scala plugin to work faster. Otherwise GC will cause freezings, and important caches will be cleaned too early.
Typing cause CPU usage, because we need to rehighlight changed file, and CPU usage is not an issue, it's issue only if typing is freezing. You've not mentioned IDEA and Scala plugin versions. IDEA 10.5 has problem with autopopup completion, so you can try upgrade it to IDEA 10.5.1.RC or you can try to disable autopopup completion. The latest nightly build of scala plugin works faster.

Best regards,
Alexander Podkhalyuzin.

Can we have a new release please :)

I noticed few problems here, it definetely will be after fixing this.

Best regards,
Alexander Podkhalyuzin.

Hi Rhys,

Here are the memory settings I use in idea.vmoptions with a 64-bit VM:

-Xms256m
-Xmx1024m
-XX:MaxPermSize=384m
-XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC
-XX:+HeapDumpOnOutOfMemoryError
-XX:ReservedCodeCacheSize=128m
-ea
-agentlib:yjpagent$BITS=disablej2ee,disablecounts,disablealloc,sessionname=IntelliJIdea10

With these settings, memory doesn't appear to be a problem for Idea at all - where I have a problem is that CPU usage appears quite high.  I have eight cores at work, so life is tolerable there, but Idea has been stress testing the quadcore i7 on my laptop lately.

Another factor is - how much memory does your machine have?  I work on a large multi-module Scala project - I don't even try to compile in Idea, I use sbt from the command line - and know from experience that to run Idea, two or three sbt sessions, plus the app I work on, plus Firefox (now there is a memory hog!) that I need a minimum of 8GB of memory.  Your baseline may be different, but look at the memory stats for your system and see how hard your machine is swapping.

Using Pavel's suggestions above to switch versions of Idea and the nightly plugin, the situation seems slightly improved: no more delays while typing, but autocomplete is still sulky and autoimport insists on trying to autocomplete closures with nonsense.  But nightly build 0.4.1144 has some good ratings, so I am off to give it a try!

I have to agree with Rhys' assessment here. Short files are okay, the syntax checking and inspections complete fairly quickly (under a second or two). However, past a certain point, the syntax checking and inspections take longer than it takes SBT to compile my changes! And while it's doing the syntax checking and inspections, my Core i7 is maxed out.

The memory use seems to be quite rampant. Starting from a base of ~100M out of ~500M used, editing a Scala class will result in the memory use jumping up to ~400M used as it does the syntax checking and inspections. And these appear to be temporary objects that are escaping the eden space and getting into the perm gen because clicking the GC button will get it back down to ~100M but otherwise it just continues to hover around that mark.

I start with a base of 250M out of 1011M, and memory usage fluctuates but rarely goes past 300M even with many 100+ line files open.   Last year I used to experience memory problems exactly like you're describing, but things have been good for me since late 2010.

Agree that syntax (re-)highlighting has been dog slow lately.  But even under those conditions memory usage doesn't spike for me.  Curious!

Using idea-IU-107.277 with nightly build 0.4.1144 (jvm 1.6.0_24 64-bit) and I think today is going to be a good day.

I think the plugin build I'm using is a week or two old, so maybe I should try the latest.

Thanks for the suggestions guys.

I'm using IDEA 10.5 Build 107.105 with Scala plugin 0.4.1084 on Windows 7 64-bit, with a 2.8 GHz dual-core processor.

I updated the vmoptions as suggested but it makes no difference. I also disabled Autopopup and Scala type-aware highlighting. I'm using about 2.2 out of 4 GB of system memory, so memory doesn't seem to be the problem.

Alex - "CPU usage is not an issue, it's issue only if typing is freezing" - yes, that is my issue, that typing is freezing. Not for long periods of time, mostly less than a second, but typing is a feedback process where I rely on seeing what I have typed immediately, so any delay at all kills the rate at which I can type. Sluggishness is not just annoying: it makes me far less productive.

It's not like a 150-line file is even very long. I should be able to edit 5000-line files... in fact the length of the file shouldn't make any difference at all when all I'm doing is changing one letter in one line of code, or inserting a line. All we're doing is editing a text file and adding some highlighting - it's not like we're trying to run Crysis on maximum settings (which works fine on my machine, btw).

Although I know nothing about how the Scala plugin is coded, it seems like you're trying to re-calculate highlighting and maybe verify syntax on the whole file every time I type a character. There must be a leaner, more efficient way... responsive IDEs have been around for decades running on machines with a tiny fraction of the processing power of mine.

Unfortunately my internet connection is slow and I am just an average user - I can't spend time messing around with release candidates and nightly builds that may not have addressed the problem. Given that the suggestions here did not work for me, it seems the cause of the problem is not currently known, so it is unlikely the latest builds will have fixed the issue.

We recommend everyone to use 0.4.833 version of the plugin until we fix the performance problem.
We're really sorry for the inconvenience.