Java IDE Performance

An interesting discussion popped up on DZone last week. In a discussion of this link on DZone, the author of the post in question mentioned the poor performance of most Java IDEs, and I think he has a valid gripe: Most (if not all) Java IDEs are performance hogs, sucking up a lot of CPU and RAM.

Before anyone gets all hot under the collar about their favorite IDE and starts flaming me, let me be clear: All of the major players in the Java IDE world -- Eclipse, Netbeans, and IntelliJ IDEA -- are fantastic pieces of software from a feature standpoint and I've used just about every one of them at one time or another, with Eclipse being the mainstay for my day-to-day work currently. Given the current state of the art in Java IDEs compared to my early days in Java development (late '90s) I will take what we have now without question.

But I don't think any Java developer out there can say that these IDEs don't suck up system resources like crazy. Regardless of the hardware I've run on, I still run into long load times, laggy auto-complete when I type, and just general slowness...to say nothing of memory consumption. And the larger a project gets, the worse the situation becomes.

As far as I can tell, performance is still an issue for most of the major IDEs in the Java development world.

Now, maybe it's not a terribly big deal for a lot of Java developers out there -- I don't see a lot of discussion about IDE performance in the Java community these days. Perhaps everyone's just learned to live with it. Or perhaps it's just an issue for those of us in software development that don't have the luxury of monster-sized Quad-Core systems with 8+ Gigs of RAM, and sporting a Solid-State Disk for maximum performance. In other words: All us lowly enterprise developers who are at the mercy of our IT departments.

At any rate, even if you're sporting the best development system money has to offer, odds are you've had to deal with IDE performance at some point or another when doing Java development. The question is what's causing all of our favorite IDEs to perform so poorly in terms of both speed and memory footprint?

A few thoughts come to mind...

Java
Of course, we can't have a discussion of performance without thinking of the underlying VM upon which the major IDEs run. Despite the heretical nature of the "Java is slow" argument within the Java community, this is certainly a valid argument to make here since all of the major players in this space are written in Java, as far as I can tell. We could spend days arguing over whether Java really is slow compared to native code (and there's been plenty of arguments about it since Java's inception), but the fact is that you are running bytecode in a VM, which no matter how you slice it is going to be slower than native code in a lot of cases. And given the relative size and complexity of the pieces of software in question, I think it's a valid point to consider when it comes to IDE performance.

Of course, a question I have here is this: Why aren't there any popular natively-compiled IDEs for Java? I know it flies in the face of Java's overarching premise of being platform-neutral, but wouldn't having some form of high-performance, compiled IDE be useful to developers? Couldn't the free software or open-source communities get something going along these lines, creating an open-source, natively-compiled Java IDE that could be ported to the various platforms?

Thinking about this further, Eclipse itself leverages the widget set of the underlying OS via SWT, which means it's effectively leveraging native code to improve performance already (and this was in fact a major motivation for SWT's creation to begin with), so why not just take it a step further and make a native-code IDE?

The closest thing I've ever seen to a resource-friendly IDE that wasn't written in Java is the Java Development Environment for Emacs (JDEE) which, despite being a nice and speedy environment to work in, is still somewhat lacking in its feature set and is a bit hard to just jump into for most developers -- especially when you need to learn Emacs in order to use it effectively.

Anyone that's familiar with Emacs, however, will point out something interesting here: The JDEE isn't a natively-compiled IDE either -- it's written in elisp -- which actually raises more questions about the possibility of whether the Java platform itself really is a performance problem or not. Since elisp is interpreted code, yet the JDEE performs exceptionally well, perhaps the whole interpreted code thing might not be such a big deal after all.

Architecture
This, of course, brings us to the subject of the underlying architecture upon which these IDEs are built. It is certainly possible that the architecture of the IDEs themselves are just lacking, making them inherently slow. And with the growing list of languages and technologies that many of them try to support, it makes it more likely that the underlying architectures of the various IDEs can only handle so many things before they begin to buckle under the weight of it all.

Based on my own look into the Eclipse RCP architecture, I'd have to say that this is certainly a possibility. It's designed to be as generic as possible and support a wide range of possible uses, and as a result may not be perfectly tuned for software development the way it once was. I haven't looked at the Netbeans architecture, and can only guess that it would face a similar situation as Eclipse in terms of design.

IntelliJ IDEA may be the one with the advantage in this regard as I don't see anything to indicate that it's tried to be anything more than a feature-filled IDE. But nevertheless, it's still trying to support a lot of uses, which can affect performance.

I'd also like to think that since most of the major Java IDEs have been around for a decade or more, they'd have at least some focus on performance in their respective architectures for at least part of that time and have kept that at the forefront of all of their design decisions. Still, there is the possibility (at least in the case of Eclipse and Netbeans) that they've overextended by trying to be too generic.

Java Project Complexity
Another possibility -- and one that I think warrants some attention -- is the very nature of most Java projects and their sometimes dizzying amount of complexity and the array of tools that can be required to easily navigate and maintain such projects.

When a "simple" web project is using the likes of Spring, with Hibernate linking the database, along with any number of JSPs, or perhaps even some GWT or other AJAX-like technology in the web pages, all tied together by a multitude of libraries, XML files, property files, i18n support, and various bits of technology, it's no wonder the IDE might start having spasms. There's a lot of parsing that has to go on.

Of course, this touches on a bit of the other two points -- if the IDEs are designed and architected right then they should be able to handle this sort of thing. But since these days a lot of these IDEs are not necessarily optimized for just one type of project, or even one type of language for that matter, this might not be something that's easily addressed.

Maybe the IDEs are a little over-generalized to support too many things at once...?

Etc...
I'm sure there's something else out there that I'm missing, so feel free to jump in and add in your own theories.

I don't really have any solutions here, just some thoughts about the current state of Java IDEs. I think all the development platforms we have now are great in their own ways, and give us plenty of options.

But I can't help but feel that maybe we've all just settled for what works, without thinking about if we could be getting more out of our IDEs in terms of performance. Have we just accepted that things are as good as they're going to get?

I actually managed to use the JDEE on a project a few years ago and found it immensely more productive compared to Eclipse -- aside from the production boost that I got just from using Emacs (which I do miss these days), the performance of the environment in general was considerably faster than Eclipse, and I felt that I was able to be a lot more productive on that project than had I been using one of the other popular IDEs.

Unfortunately, I had to abandon the environment when I switched to a web application project -- the JDEE doesn't do web app development very well from what I've seen. Nevertheless, I still miss the amount of productivity I had.

I guess the question is...does anyone else?

Maybe this is a case where a developer who hasn't explored Java outside of the popular IDEs, who has spent most (or all) of a career working with the likes of Eclipse and such, just doesn't know any better and thinks that Java development is as fast as it can be based on those environments -- They basically don't know what they don't know.

At any rate, I think this are all valid questions we should be asking: Can Java IDEs get any better on the performance side? Should we accept the current status quo? Would we be better served by a native IDE client?

I'm curious to know what other developers think about this.