It’s been more than two years since I’ve personally switched from using Eclipse as my main Java IDE to IntelliJ IDEA. I still remember my first impression of IDEA, in fact I still recognise it every time I fire up a new window: faster and more responsive. I cannot say Eclipse was slow or unreasonably laggy (unless it tried to build the workspace and save a file at the same time), but IDEA felt somehow different.
That said, I do still continue to use Eclipse now and then, and responsibly update my Eclipse installation to newer versions as well as follow it’s development efforts quite closely.
Eclipse has major releases every year around June and 2015 is no exception. Eclipse Mars is scheduled to land in the beginning of summer and there are milestone packages already available now. Eclipse Mars Milestone 6 is out, seven is right around the corner and that means even the most eager users can consider safely upgrading their main instance of Eclipse. If you’re not very familiar with the development process of Eclipse, M6 is an API freeze and M7 is a functionality freeze. So if you upgrade today there will be only bugfixes introduced in later updates, which should greatly reduce the risk of being upset in future.
Naturally, after a year of development many things will get better, more user friendly, and stable. But what I really look forward to each year are the performance improvements. All other functionality just mostly exists, and since I’m not an extremely active user, I don’t get that excited about Mylyn integrations or new UML editors. But performance is something every user experiences, and it makes it one of the most important UX features any product can have.
At the same time, keeping in mind that ZeroTurnaround offers it’s own performance related product: lightweight Java profiler – XRebel, performance topic is even more interesting to me.
In this post I’ll try to shed some light what performance improvements are coming with Eclipse Mars and explain why and how should it impact your everyday development life. The main source of such information can be the New and Noteworthy Eclipse Changelog, but it includes many more features and it is quite easy to lose yourself in.
Improved compiler performance
The first improvement we’re going to look at is a result of tireless work of Lukas Eder, the man behind jOOQ, typesafe DSL for SQL. He said in his interview after the Virtual JUG session that he prefers Eclipse, but not only does he use it extensively, he also from time to time submits tickets to their bugzilla issue tracker. Which is what every developer should do when they encounter weird behavior or bugs in any tool.
Anyway, thanks to the ticket Lukas submitted, the performance of the Eclipse Java compiler has been improved for the code that features lots of generics, both on type level and for overloaded parameterized methods.
Compilation is one thing IDE does frequently. More frequently that almost anything else perhaps, and any slowdown in this area will be quite annoying. The compilation speed is actually one thing that differentiates Eclipse from IntelliJ IDEA, since the latter compiles Java code in a separate process, which reduces the resources overhead needed to be included in the main IDE process, but is largely a negligible performance overhead. So, I’m really happy to see that Eclipse Java compiler got even smarter and that Mars will become even faster when compiling projects.
UI responsiveness monitoring
Next is, perhaps, my favourite performance related improvement that will ship with Eclipse Mars: the monitoring of UI responsiveness. In my Eclipse Mars installation, it wasn’t turned on by default, so you might need to visit the preferences to enable it manually. However, it’s an extremely promising monitoring feature. To enable it just Quick Search (Ctrl + 3 / Cmd + 3) for “responsiveness” and enable the “Detect periods of unresponsive UI” checkbox.
Behind the scenes now, the thread responsible for UI actions will be periodically checked and if it does not change its activity frequently enough, its stack trace will be recorded and logged. If the period of inactivity is longer than the larger threshold, it will be treated as an error, which it actually is.
In the worst case, a deadlock is suspected and even more information is logged to ease debugging. Naturally, you can specify filters if you want to relax the checks or make even background threads’ information to be logged.
You can tell this is a promising feature and it has improved, since it was first included in M3 update. So the Eclipse team pays attention to it and hopefully by gathering the information about what that sneaky UI thread is doing when no progress is seen, we’ll have a better idea of what to fix.
Personally, I haven’t got any notifications yet, but I’m keeping an eye on the logs. If you have any success at catching a deadlock or an UI freezes, please ping me on Twitter: @shelajev. I’d love to hear a success story.
Default max heap size increased to 1024 MB
Another performance improvement that went into Eclipse Mars, is related to memory. For the longest time, Eclipse has been using quite conservative default values for heap sizes. Can you imagine that in our age of super powerful developer machines that almost drown in RAM and excessive CPU, the memory settings in the out of the box Eclipse were just 40M and 512M for the minimum and maximum heap sizes respectively. If you’re confused, minimum heap is what you specify with -Xms and the maximum is -Xmx. Now these has been bumped up to 256M and 1024M. Which is great because that is one of the optimisations that Optimizer for Eclipse is doing among other things.
In case you weren’t aware, Optimizer for Eclipse is a free Eclipse plugin, developed by ZeroTurnaround, aimed at automatically finding and fixing common Eclipse configuration issues to make your IDE faster and more responsive. We’ve had great feedback about it on Twitter, and have had over 7000 installs in our first month! So check it out, it will help with Eclipse performance, even if you don’t plan to upgrade to Mars yet.
Job Group API
The last thing I want to share today is the new JobGroup API that that makes it easier to implement parallel and asynchronous algorithms in Eclipse. The new API supports throttling, joining, cancellation, combination of progress and error reporting for all of the jobs in a group. There’s a design discussion Google doc available, that you can browse through to learn various things from how cancellation policies work to API usage examples. In a nutshell, the JobGroup API makes it much easier to handle multiple threads that execute small pieces of a larger task and how to handle all those threads in a uniform fashion. Hopefully, the next minor releases will make extensive use of it and various tasks will become swiftlier.
One example of such an improvement is already available now. The plain text search speed has increased by around 3-4 times. Search is a classic example of easily parallelizable problems, and a feature that is undoubtedly in daily use by Eclipse users. The implementation details of how the search feature has been reworked can be found in Eclipse Bugzilla.
Thanks to the Eclipse team!
Naturally, the improvements in Eclipse Mars are not just related to performance. Other important things have been added like inferring the parameter types of a lambda and converting method references to lambdas and back, as well as tons of other fixes and features.
In this post I wanted to look at the changes that are directly related to the IDE performance and I hope you had fun going through them with me.
All in all, I’m really excited about this year’s Eclipse release and am looking forward to see how it performs on the main projects I deal with. For now it looks amazing! Big-big thanks to the Eclipse development team for doing such a great job!
Do you have a favourite feature in the upcoming Eclipse Mars release? What are you personally most looking forward to? Leave a comment below and chat with me on Twitter: @shelajev.
Also just before I go, I want to point you to a Java 8 vs Java 7 performance comparison blog, which was so fun to write, and I think you might really enjoy reading it.
RebelLabs Perfomance Survey!
Oh, one more thing, since you’ve made it this far, I guess you’re kinda interested in performance. RebelLabs yearly survey is currently active and it focuses on Java performance. It would be amazing if you could respond to those questions, it’ll take a couple of minutes at most!
And then share it with your colleagues and friends. Please. The more data we get the more interesting the analysis report will be. We can make it awesome. Thanks, here’s the button that’ll take you to the survey: