Major slowdowns

[Zach Cox]

Something else I've noticed since upgrading to Ubuntu 11.10 is that after using ensime for awhile, my whole system slows way down. Keystrokes in emacs don't appear on-screen for several seconds, every app is slow, etc. I don't know 100% that this is caused by ensime, but it seems that if i reboot and don't use ensime, it doesn't happen. But once I start using ensime (editing .scala files, saving, etc) then things will start to bog down after awhile. This never happened before using Ubuntu 10.04 and older releases of ensime - one of the things I liked the most about emacs+ensime was how fast it was.

Has this been reported by anyone else? Am I just crazy?

Thanks,
Zach

[Aemon Cannon]

Hasn't been reported before. Could you check your activity monitor to see if ensime is leaking memory?

[Zach Cox]

Sure - so you mean the java process that goes along with ensime, not
the emacs23 process, right?

[Aemon Cannon]

Correct. And if you could put a finger on what ensime operation is correlated with the memory increase, that'd be awesome.

[Zach Cox]

I can say that the only things I've done that precede the slowness are
edit & save .scala files and mouse-over compiler errors. No C-c C-v
stuff, no ensime-refactor, etc. Just editing, saving & hovering.

[Aemon Cannon]

hmm, ok. 

I'm definitely curious if the size of the jvm is growing continuously.

[Zach Cox]

I just made a small change to a unit test, C-x C-s to save, and now
ensime's java process has been at ~ 95% CPU for a few minutes.
inferior-ensime-server showed it parsing & type checking a lot of
.scala files. This seemed to go really slow.

Now that java process is back down to 0% cpu, but the whole system is
still running extremely slow. System monitor doesn't show any
processes chewing up cpu.

Every time I edit & save a .scala file, everything (including the
parsing & type checking in inferior-ensime-server) seems to run slower
& slower.

That java process started at 1.5 GiB, went up to 1.6 GiB after the
first save and is now at 1.7 GiB after the 2nd save. The type checking
for the 2nd save went on for about 10 minutes.

[Zach Cox]

After two more edit-save cycles, that java process is at 1.8 GiB.

[Aemon Cannon]

"The type checking for the 2nd save went on for about 10 minutes."

That's way beyond anything i've ever seen. What platform are you on? OS,RAM, etc?

Is this behavior displayed in the sample project you sent me?

[Zach Cox]

Dell laptop, Intel Core i7 CPU Q 720, 8GB RAM, Ubuntu 11.10 64-bit.

The project this slowdown happens with has 361 .scala files in src/main/scala, with a *very* rough LoC count of around 35k, and 145 .jars in lib_managed.

I am not able to cause this slowdown in that example project on github.

[Zach Cox]

I noticed this at the very beginning of inferior-ensime-server when
M-x ensime'ing my project:

java -classpath ... -Xms256M -Xmx1512M ... org.ensime.server.Server
/tmp/ensime_port.4348

1512M is about what the ensime java process was using during the
slowdowns. Next hypothesis is that ensime is running out of heap
space. I tried setting the ENSIME_JVM_ARGS env var as per the ensime
user manual:

$ echo $ENSIME_JVM_ARGS
-Xms1024M -Xmx3072M

But this had no effect the next time I started ensime. What is the
best way to give ensime more heap space?

[Zach Cox]

I ended up just setting the heap sizes directly in the
ensime/bin/server script. That java process now uses 2.0 GiB after
initial startup, so I'm assuming max of 1512M was way too small for
this project. After 1 edit & save that jumps up to 2.4 GiB. Another
couple edits & saves got it to 2.6 GiB, then a lot more got it to 2.7
GiB, and then a lot more got it to 2.8 GiB. So ensime is using a lot
of ram, and possibly leaking it at a fair rate, but no slowdowns yet.
Although I imagine it will eventually outgrow the -Xmx3072M value and
then I'll see slowdowns again.

Compiler errors also seem to take a lot longer to show up now.
Introducing an error into a 300 line unit test and then saving takes
5+ secs to highlight the error. Seems like it used to be almost
instantaneous.

So I think this shows that 1) slowdowns are a result of ensime running
out of heap, and 2) ensime heap usage does grow over time, possibly a
leak, caused by simply editing & saving files.

Thanks,
Zach

[Brad Noriega]

I posted a message yesterday, but I guess it didnt get through
somehow.

I got the same problem. I just moved from IntelliJ to emacs+ensime
because I'm coding over SSH,
as soon as I started M-x ensime , it eats up my RAM.

inferior-ensime-server shows that it loads every single dependencies
that I dont really need.
So I tried to disable indexing in .ensime file by using:
:exclude-from-index ("com\\\\.sun\\\\..\*" "com\\\\.apple\\\\..\*")
however, im not experienced in regex, can somebody explain me what
does the double backslash used for.
If i want to exclude com.eclipse and org.slf4j, is this the right
way ?
:exclude-from-index ("com\\\\.eclipse\\\\..\*" "org\\\\.slf4j\\\\..
\*")
is there a way to whitelist indexing instead ?

another thing is that, my server only has 512MB, is this not enough ?
What is the min. memory requirement for ensime ?

My project is using: emacs 23.2.1, scala 2.9.1, akka 1.2 with spray ,
sbt 11.1, ensime 2.9.2-SNAPSHOT-0.8.0-RC3.
Small sized, only around 10 files.

Thanks.

[Aemon]

As I mentioned in the other thread - ENSIME wants more than 512MB.
I've never tried to use it on less the 2GB. The compiler eats up a lot
of
memory, and the indexer eats up a lot of memory. It's unfortunate.

[Aemon]

Zach,

I've done some testing using the lift project that you gave me.
I know that's just a sample project, but it doesn't exhibit the
unchecked growth that you
are describing (levels out around 620). Is there a github project that
will reproduce this issue? Thanks

[Zach Cox]

Hi Aemon,

Our project (which we really can't release) contains 361 .scala files. It looks like the entire Lift framework project https://github.com/lift/framework contains 414. I haven't tried, but maybe that entire code base could be loaded with ensime? Or at least the biggest subproject?

I am almost starting to suspect the combination of Ubuntu 11.10 + scala (or java?) as a major part of the problem. If I recompile this entire project and run all unit & selenium tests just with sbt, I see the same behavior: it eats up almost 4GB ram, slows way down towards the end of the tests, and then for 10-15 mins after sbt stops the system is just crazy slow. Maybe there's something off with processes that use this much ram in 11.10? I dunno. I don't remember having these issues on Ubuntu 10.04. I may downgrade.

Thanks,
Zach

[Aemon Cannon]

Oh, interesting. The lingering slowdown is very strange.

[Zach Cox]

Yes strange and extremely annoying. Can't tell you how many times I've rebooted this laptop in the last week.