Demetra Hotswap performance - 100x slower than Eclipse

I'm using IDEA 6.04 on Windows XP, remote debugging a local Tomcat instance. Whenever I try to hotswap a changed class, it takes over a minute to swap the new class in. For a while I'd been assuming that this was just because it was a reasonably large project I was debugging (several thousand classes), but a few days ago I tried using Eclipse for the same thing, and Eclipse took less than a second to do similar hotswapping.

I've tried JDK 5.0.10 and JDK 6, switched between debugging via socket and shared memory, fiddled with memory settings, but nothing helps. Whatever I do, IDEA is about 100 times slower than Eclipse. Short of downloading Eclipse and using it for hotswapping while I develop in IDEA, I don't know what else to try.

Am I the only one with this problem? How long are people normally waiting for Hotswap to complete?

13 comments
Comment actions Permalink

idea's hotswap is a lot slower, but it actually works. i guess it takes that long because idea checks all files for modifications. eclipse just skips this, which results in a faster hotswap, and sometimes obsolete class files, but new sources, or mixed and obsolete class files which can drive you crazy while debugging.
an "hey idea, i'm absolutely sure that the checks can be skipped"-option would be nice.

0
Comment actions Permalink

Please check out hotswap performance in the coming Selena build. If everything is ok, we'll backport the change to Demetra (IDEA
6.0.5).

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"HamsterofDeath" <h-star@gmx.de> wrote in message news:9916643.1169805612210.JavaMail.itn@is.intellij.net...

idea's hotswap is a lot slower, but it actually works. i guess it takes that long because idea checks all files for modifications.
eclipse just skips this, which results in a faster hotswap, and sometimes obsolete class files, but new sources, or mixed and
obsolete class files which can drive you crazy while debugging.
an "hey idea, i'm absolutely sure that the checks can be skipped"-option would be nice.



0
Comment actions Permalink

i never had a problem. the most time was used for scanning directories and files for changes. the hotswap itself was always done within seconds, even if there were a dozen changes classes.

0
Comment actions Permalink

Thank you! I'll try it in the next Selena.

0
Comment actions Permalink

Now for such number of changed classes it will be done in milliseconds :)

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"HamsterofDeath" <h-star@gmx.de> wrote in message news:6376545.1169820137353.JavaMail.itn@is.intellij.net...
>i never had a problem. the most time was used for scanning directories and files for changes. the hotswap itself was always done
>within seconds, even if there were a dozen changes classes.


0
Comment actions Permalink

I have seen the complains about debugging speed and have experienced the
problems myself on Weblogic, JBoss and SJSAS. IDEA really isn't that bad
compared to Eclipse (Eclipse is fast, but not nearly as reliable, as discussed
in this thread), but it isn't all that pleasant of an experience.

Recently, a part of the application that I'm working on needed to exist outside
of a J2EE server. This included about 50% of the bloated code base, including
a Hibernate mapping of massive schema, heavy use of Spring, 1000's of project
classes and 20MB of libraries, (done to make it easy to share code between
the two). When debugging both the J2EE server and the stand-alone part,
the difference in debug and hotswap performance was extreme.

The J2EE setup was: SJSAS, debugged as a remote process on localhost, not
as an instance of Glassfish -- for legacy + Eclipse reasons, our build is
too complex to allow IDEA to assemble the app, unfortunately. The J2EE server
debug experince included all the normal performance problems that have been
brought up here. More than anything, it "feels" sluggish. This is particularly
noticable with hotswap, which frequently pauses for 10+ seconds with no progress
indications.

The stand-alone setup was in the same IDEA project, just a separate module;
it was also debugged as a remote process on localhost. The stand-alone process
was nearly flawless, consistently responsive for all opearations, including
hotswap, which hardly ever had a significant pause.

Could it be that those complaining about debug performance work with J2EE
servers, but those that think its fine are working with stand alone Java
processes? On the face of it, this seems unlikely -- recent versions of
IDEA itself must be at least as complex as a J2EE server. The only major
difference that I can think of is that J2EE servers interact far more with
the network than any other type of application. Maybe something in the JVM
interferes with IDEA's approach to using the debug API?

--Mike


0
Comment actions Permalink

Could it be that those complaining about debug performance work with J2EE servers, but those that think its fine are working with
stand alone Java processes? On the face of it, this seems unlikely -- recent versions of


Yes. I'm pretty sure that the app servers are best applications that illustrate all performance bottlenecks of debugger. For
example, there are many threads in a typical app-server process and some JPDA thread operations (e.g. suspend/resume) are
time-expensive. So for app servers the overall slowdown becomes noticeable.
The slowdown of hotswap was caused by the fact that IDEA prepared a list of methods being executed (for all the threads). All this
was done just to show a warning that breakpoints will be ignored for the obsolete methods (in case obsolete methods were found on
the stack after the hotswap)

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

I've tried hotswapping using Selena 6667 now... it's superb! Hotswapping is now effectively instant.

Great job, thank you. I'm looking forward to the 6.0.5 backport.

0
Comment actions Permalink

all the threads). All this
was done just to show a warning that breakpoints will
be ignored for the obsolete methods (in case obsolete
methods were found on
the stack after the hotswap)


And it was incredibly obnoxious, most of all!!!

0
Comment actions Permalink

i tried it, too, but it didn't work.
1. there is no "X classes reloaded" message on the bottom like usual.
2. old code is executed instead of the new one
3. no error message like "i couldn't do it because...." popped up
no red circle.

i tried it about 15 times, and it worked twice until now.
i'll try it using an empty 1 class project and see if i can reproduce it.

0
Comment actions Permalink

Not repeatable for us.
Did you manage to create the project illustrating the problem?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"HamsterofDeath" <h-star@gmx.de> wrote in message news:33097102.1170075971849.JavaMail.itn@is.intellij.net...

filed: http://www.jetbrains.net/jira/browse/IDEA-11295



0

Please sign in to leave a comment.