Longtime user noticing perfomance decrease...

I've been using IDEA for a couple years (yes I bought a license) and I've run many different builds in that time.
I've been noticing a rather disturbing generalized trend, the newer the build, the poorer the performance despite my having faster hardware with more memory. As of this morning I'm running build 944 but I've noticed the behaviour I am about to describe for a long time.

I've seen some discussion on memory usage/leakage and tried some of the suggestions but I still have the problem that IDEA reports memory usage radically lower than what Windows Task Manager reports, and, as memory usage in IDEA increases, it increases faster in the OS.
When I opened IDEA this morning it started with 23M of 41M showing, Windows however showed 83M. A few minutes later IDEA showed 25M of 48M and Windows showed 96M. I opened a couple Java files and one JSP and ran an Ant build from within IDEA of my entire project; memory usage in IDEA changed (after clicking the GC button) to 32M of 70M but Windows now reports 105M. This of course continues throughout the day until I restart to clear out the unneeded memory usage. No amount of clicking the GC or setting command line startup parameters in the .lax file seems to help.

Another performance issue I've been increasingly discturbed by is the scanning/parsing of files that are not in my project when I start, my project (which only has 136 files) took about 8 minutes to open this morning on a 2GHz machine with 512M Ram. This wasn't because of all the files in my project, it was because IDEA spent 5 minutes scanning and parsing the entire JDK 1.4.2! and another 3 minutes on my other various libraries. Why would it ever need to parse my already compiled libraries even once much less all the time? And for the record I have local VCS turned off. Turning that on has ground every project I've opened to a halt.

A similar thing to this is the "Optimizing Performance" feature, prior to this "feature" my install of IDEA ran smooth and fast, still some memory issues, but smooth and fast. It was a beautiful IDE and I loved using it. Now however, I sit and wait several minutes whenever I add a new library or do something else to cause it to "optimize performance". I don't know what's going on in the background or what the intended result of this "optimization" is but it certainly isn't optimizing my performance when I can't work for several minutes every time it feels like locking up to "optimize". Personally I don't think it performs nearly as well now as it used to when it didn't "optimize performance".
I used to run IDEA on a P2 400MHz and that version ran faster than the newest ones do now on my 2GHz P4.

I still like IDEA but I would like to know what, if anything, can be done about these issues? And if anyone outside of the companies I've worked for has experienced similar results? I know that people I've worked with on various projects have all experienced this so I don't think it's isolated to me.

Thank-you for any thoughts, solutions, suggestions, etc.

Sincerely,
David Duffy

12 comments
Comment actions Permalink

Are you talking about the EAP version? That is, after all, an early access, pre-release, unstable, and unoptimized piece of software. And it is intended to be at this point. I do agree with and have (painfully) experienced all that you've mentioned, but I think it's a bit premature to rant about the performance of a product that isn't released yet.

0
Comment actions Permalink

One of the IntelliJ guys promised that before final release that Aurora
performance would be faster than 3.0.x. I'd reserve judgment on it until
the product is released. Hopefully they will be moving into optimization
work soon.

Jon

0
Comment actions Permalink

Hopefully they will be moving into optimization work soon.


I would be satisfied, if I could use the next build...

Tom

0
Comment actions Permalink

Try these settings:

lax.nl.java.option.additional=-Xms64m -Xmx128m -XX:+UseParNewGC+UseConcMarkSweepGC -Djars.nocopy=true -Didea.no.jdk.check=true -Didea.system.path="~
.IntelliJIdea
system" -Didea.config.path="~
.IntelliJIdea
config" -Didea.popup.weight=heavy

They work quite nicely for me. The Project I'm working on has ~500 classes.

HW: compaq laptop with 1,6P4M and 512MB ram.

P.S.
I'm using the 944 build.

P.S. II
I've disabled all the plugins I don't need. (starteam, tomcat, uidesigner). Additional plugins that I have: (RemoteSynchronizer, Scratchpad and SimpleUML).

0
Comment actions Permalink

Thank-you for the settings suggestions, I've been running with them for the last few weeks and I'm not sure if it has made a difference or not, I've still had several instances where all of the jar files have been copied (even making duplicate copies with different hashes appended to their names) and the JDK source is scanned.

But the big killer for me is the constant memory leak, no amount of clicking the GC button helps (with or without the new settings). Yesterday IDEA completely locked up on me after running for only two days and gave a message indicating I should post a bug about the Out of Memry error and exit and restart. I couldn't even exit because it kept putting up the same message each time I trie. I found that the issue was already reported way back in build 666 and I was running 957 (I've switched to 963 this morning...).

On the bright side there are a couple things I have noticed improvement in, the overhead of allocated memory in the OS beyond the 127 claimed by IDEA has gone down significantly with the new GC ssettings you suggested and this morning when I switched to build 963 it started very quickly which I hope continues.

0
Comment actions Permalink

Hezekiel wrote:

Try these settings:

lax.nl.java.option.additional=-Xms64m -Xmx128m
-XX:UseParNewGCUseConcMarkSweepGC -Djars.nocopy=true


This doesn't seem right. Parallel and concurrent gc at the same time?

Either use:

-XX:+UseParNewGC if you have a multi cpu machine (or one of the latest
hyper-threading pentiums?).

or

-XX:+UseConcMarkSweepGC to enable concurrent gc. This has helped some
users (me included :-). It is supposed to be 1: slower than standard
gc, 2: have fewer pauses than standard gc (more responsive).

0
Comment actions Permalink

hint: I've been realized that saving the files before GC frees up much
more memory.

Sven
David N. Duffy wrote:

Thank-you for the settings suggestions, I've been running with them for the last few weeks and I'm not sure if it has made a difference or not, I've still had several instances where all of the jar files have been copied (even making duplicate copies with different hashes appended to their names) and the JDK source is scanned.

But the big killer for me is the constant memory leak, no amount of clicking the GC button helps (with or without the new settings). Yesterday IDEA completely locked up on me after running for only two days and gave a message indicating I should post a bug about the Out of Memry error and exit and restart. I couldn't even exit because it kept putting up the same message each time I trie. I found that the issue was already reported way back in build 666 and I was running 957 (I've switched to 963 this morning...).

On the bright side there are a couple things I have noticed improvement in, the overhead of allocated memory in the OS beyond the 127 claimed by IDEA has gone down significantly with the new GC ssettings you suggested and this morning when I switched to build 963 it started very quickly which I hope continues.


0
Comment actions Permalink

This doesn't seem right. Parallel and concurrent gc
at the same time?


Parallel and concurrent may indeed work together, since they work on different heap areas and run under different conditions: the parallel collector scans the young generation areas, and the concurrent collector scans the old generation one. The problem with parallel collection is that it really makes sense on multi-processor machines only, on a single processor machine that switch has no effect, and the JVM reverts to the default collector.

-XX:+UseConcMarkSweepGC to enable concurrent gc. This
has helped some
users (me included :-). It is supposed to be 1:
slower than standard
gc,


Actually this is not true at all! You may want to run the ide in the two different conditions with some gc logging turned on and you will have a clear indication of the (pretty huge) difference.

0
Comment actions Permalink

The parser is also painfully and irritatingly slow, as of its current state.

0
Comment actions Permalink

BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah it might be weird but it works, it does on my box and it allows me
to work with the latest EAP. Performance is better indeed, still JB
needs to do some performance tuning things are deteriorating rapidly, or
so it seems. (Yes I've filed bugs about it)

R

Carlos Costa e Silva wrote:

| Hezekiel wrote:
|
|
|>Try these settings:
|>
|>lax.nl.java.option.additional=-Xms64m -Xmx128m
|>-XX:UseParNewGCUseConcMarkSweepGC -Djars.nocopy=true
|
|
| This doesn't seem right. Parallel and concurrent gc at the same time?
|
| Either use:
|
| -XX:+UseParNewGC if you have a multi cpu machine (or one of the latest
| hyper-threading pentiums?).
|
| or
|
| -XX:+UseConcMarkSweepGC to enable concurrent gc. This has helped some
| users (me included :-). It is supposed to be 1: slower than standard
| gc, 2: have fewer pauses than standard gc (more responsive).
|
-


BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)

iD8DBQE/s46/+cV9vuB27SARAk92AJ4laEevsTk0nf8Qdz4jnBrYq7PqkACeJ46M
hVh2n7JFQoG/zMKH8LqYAiA=
=tHPz
-


END PGP SIGNATURE-----

0
Comment actions Permalink

It doesn't actually matter what settings you add, as long as you make some changes.

Either way, it's almost always a placebo solution, with the effects being more psychosomatic than anything else. So if you have Faith, then you'll notice a huge speedup.

0
Comment actions Permalink

Either way, it's almost always a placebo solution,
with the effects being more psychosomatic than
anything else. So if you have Faith, then you'll
notice a huge speedup.


You are probably right... but back in the days when I was using NetBeans, almost everyone was complaining for periodic ide lockups: I started using the concurrent collector, and the lockups were gone (and the reason it's pretty obvious). I remember that when I started using IDEA it was more or less the same (less lockups and shorter, but still some of them, especially after many hours of work), so one year ago I added the concurrent collector switch to my idea config, and lockups (which are in fact multi-seconds-lasting full old generation Gcs, I think) disappeared. This said, it's true that idea performance has become more painful than it used to be...

0

Please sign in to leave a comment.