Wednesday, October 27, 2010

e4.1 is Fast

I spent the morning with Eric Moffat from the Eclipse Platform Team, trying out e4.1 with CDT and RDT. We had heard a lot of complaints in the past about e4 being slow, and the Platform Team had assured us that 4.1 was doing a lot to fix that. So, we decided to give it a spin.

Eric was kind enough to sit with us and help us get up and running, which actually wasn't that hard. The compatibility layer in e4 really shines. All the JDT, PDE, and Team stuff that I use on a daily basis just worked. I added some RSE plugins to my workbench via the Indigo update site, checked out the CDT and RDT code from CVS, built it, launched it as a runtime workbench under the debugger, and I was off to the races. I was editing, compiling, and debugging C/C++ projects, both locally on my Windows box using just CDT, and remotely over the network on a Linux/PPC box using RDT.

"So, how was the speed" you ask?

In short, pretty damned fast. I never got around to trying out e4.0, so I can't comment on whether the performance there was lacking or not, but I can tell you that e4.1 feels pretty snappy. Snappier in fact than 3.6 or 3.7. I didn't put a stopwatch on it, but everything seems faster to me. Significantly faster. Startup time seems better. GUI operations all seem faster, whether it's progress monitor updates, drawing large trees full of data, scrolling windows full of content, or resizing areas in the workbench. I was skeptical going in, given the negative reviews of performance I had heard about e4.0, but I have to say that I'm pretty impressed.

The speedups make a lot of sense too once Eric pointed out some subtle things about how the UI has been redone. The workbench now uses far less SWT Composites, and less OS level widgets than it used to. That means less things to process, as well as less memory and less OS level resource consumption. They've redone a lot of other things under the hood that I'm sure are helping too. They're not done yet either. They've got quite a lot of time between now and June to make further improvements.

Now, I don't want to falsely give the impression that there were no problems whatsoever. There was the odd glitch here and there. This stuff is pretty bleeding edge though, and that's rather to be expected. We found a few issues here and there with NullPointerExceptions that didn't used to happen, for example, because the new code lacked some null checks. Eric is taking that stuff back to the team to get fixed though, and we were able to work around them.

So, is it perfect? No. But the future is looking bright, and the speed issue may have just given everyone that was taking the "wait and see" approach to e4 a reason to start looking at it again. Not everyone might care about style sheets, dependency injection, and other goodies, but we all certainly care about speed. Speed is probably the number one thing that those of us working on Eclipse products get beaten up about. The speed of e4.1 might just be the thing that makes it take off.