The Artima Developer Community
Sponsored Link

Java Buzz Forum
Is Eclipse bloated? A detailed analysis

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Markus Kohler

Posts: 74
Nickname: kohlerm
Registered: Jun, 2008

Markus Kohler is an software architect at SAP
Is Eclipse bloated? A detailed analysis Posted: Nov 7, 2008 10:07 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Markus Kohler.
Original Post: Is Eclipse bloated? A detailed analysis
Feed Title: Java Performance blog
Feed URL: http://feeds.feedburner.com/JavaPerformanceBlog
Feed Description: My blogs about Java Performance related topics
Latest Java Buzz Posts
Latest Java Buzz Posts by Markus Kohler
Latest Posts From Java Performance blog

Advertisement
On the e4 (Eclipse 4) mailing list there were lately some discussions about whether Eclipse is bloated or not, and what could be done to minimize bloat for e4. Some summary information can be found here.

I promised to get some numbers about how much memory is used by the JIT for the classes.

I finally managed it :)

So I took Eclipse 3.5M2 (without the web tools) configured it to use the SAP JVM (which is based on SUN's Hotspot, therefore the numbers should be comparable) and used the Eclipse Memory Analyzer (plus the non open source, but free SAP extensions) to generate a csv file that I then imported into IBM's manyeyes (great stuff!) to get the data visualized as a treemap.

The numbers do not include the overhead of the compiled code cache which was around 10 Mbyte.

Here comes the memory usage(in bytes) per bundle for Eclipse 3.5M2 after clicking around to activate as many plugins as possible (a more well defined test would be good idea) :



A detailed analysis would be very time consuming, because you would need to check for a lot of classes whether there's anything that could be done to make them smaller. So for now here are just some interesting observations that I made, when quickly looking over the results:
  • 12649 classes were loaded and consumed around 64 Mbyte in Perm space
  • during the test I run out of permspace, which was configured by default to 64Mbyte and the UI would freeze :(
  • there does not seem to be any large amount of generated code, and therefore optimizing classes might be difficult
  • the help system uses JSP's (generats classes) which are relatively big, also only of few of them where in memory
  • 247 relatively big classes in org.eclipse.jdt.internal.compiler were loaded twice,once by the jasper plugin and once by the jdk core plugin
I also made a detailed (per class) visualization of the relatively large jdt bundle :


So is Eclipse really bloated?
To me it seems it's overall not very bloated. Remember that a developer PC these days probably has 2 Gbyte of RAM, so 64Mbyte hardly matter.

The help system could be probably optimizied because it uses a complete servlet implementation (Jetty) including JSP's as well as a complete Text search engine (lucene).

The heap consumption could be a bigger issue. I've seen things that you should almost always avoid, like holding parsed DOM trees in memory. I may explain these issues in a later post, and I will probably show some examples in my next talk .

Read: Is Eclipse bloated? A detailed analysis

Topic: Java Term of the Week: Method Signature Previous Topic   Next Topic Topic: Jython 2.5 Beta0 Released

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use