Wednesday, May 28, 2008

Memory consumption of Netbeans versus Eclipse an analysis

I recently analyzed the memory consumption of Eclipse and found that it should be easy to optimize it.

This time I will take a look at Netbeans (6.1, the Java SE pack) using the exact same setup.

First the overall memory consumption of Netbeans is only a little bit higher 24 Mbyte versus 22,7 Mbyte for eclipse :



Keep in mind that the Eclipse memory usage includes the spell checker which needs 5,6Mbyte, which can easily turned off. Without the spell checker Eclipse would need only 17,1Mbyte

The overview of the Memory Analyzer shows that the biggest memory consumer, with around 5.4 Mbyte is sun.awt.image.BufImgSurfaceData:


Swing overhead(?)

This seems to be caused by the fact that Swing uses java2d which does it's own image buffering independent of the OS. I could easily figure this out by using the Memory Analyzers "path to GC roots query":
So maybe we pay here for the platform independence of Swing?
I quickly checked using Google whether there are ways around this Image buffering, but I couldn't find any clear guidance that would avoid this. If there are Swing experts reading this, please let me know your advise.

Duplicated Strings again

Again I check for the duplicated Strings using the "group_by_value" feature of the Memory Analyzer.
Again some Strings are there many times :


This time I selected all Strings, which are there more than once, then called the "immediate dominators" query and afterwards I used the "group by package" feature in the resulting view:

This view shows you the sum of the number of duplicates in each package and therefore gives you an good overview of which packages waste the most memory because of objects keeping duplicates of Strings alive.
You can see for example that
org.netbeans.modules.java.source.parsing.FileObjects$CachedZipFileObject keeps alive a lot of duplicated Strings.
Looking at some of these objects you can for example see that one problem is the instance variable ext, which contains very often duplicates of the String "class".



Summary

So at the end we found for this probably simplistic scenario that both Netbeans and Eclipse don't consume that much memory. 24Mbyte is really not that much these days.
Eclipse seems to have a certain advantage, because turning of the spell checker is easy and then it needs almost 30% less memory than Netbeans.

To be clear, it is still much to early to declare a real winner here. My scenario is just to simple.

The only conclusion that we can draw for sure for now is, that this kind of analysis is pretty easy with the Eclipse Memory Analyzer :)

9 comments:

Anonymous said...

It also depends on which distribution of NetBeans IDE you chose. The smallest, or the web/Java EE distribution or something different, as well as which additional plugins are installed in both.

Unknown said...

Hi "geertjan",
As I said Iused the (Java SE distribution), which does not include any Java EE functionality.

Regards,
Markus

Anonymous said...

Wouldn't this analysis be more useful if it was done with a large project loaded into the IDE? Starting size is kinda interesting, but really, when people have memory problems is when they load a big project. That's also when memory analyzers don't work so well. Have you tried analyzing a heap of 1 GB with the Eclipse memory analyzer?

Unknown said...

Hi "Anonymous",
Sure it would be more useful to have a scenario that uses more memory.
To be honest, I was surprised that the IDE would consume less than 25Mbyte.

Just using a bigger project will probably not help much. You probably would have to work on this project for a while, and therefore you would need a more complicated test case.

Yes, we(SAP) typically use the Eclipse Memory Analyzer for large J2EE projects.

A Heap Dump of 1 Gbyte is rather small one in this area.You would be able to analyze this even on 32 bit machine.

We did analyze Heap Dumps which were over 6 Gbyte on a64 bit machine.


Regards,
Markus


Regards,
Markus

Anonymous said...

In Eclipse analysis you mentioned it has 12MB of Strings - so how is it with NetBeans? Can't see it here (histogram screenshot not included). Thanks.

Unknown said...

Hi "anonymous",
There's les memory consumed by Strings in Netbeans it's only arund 5 Mbyte.

Class Name | Objects | Shallow Heap | Retained Heap
-------------------------------------------------------------------------------------------
int[] | 4.279 | 6.612.768 | 6.612.768
char[] | 47.584 | 4.269.296 | 4.269.296
byte[] | 444 | 2.055.064 | 2.055.064
java.lang.String | 54.035 | 1.296.840 | 5.213.168
java.util.HashMap$Entry | 53.596 | 1.286.304 | 5.294.624
java.util.HashMap$Entry[] | 12.268 | 1.112.928 | 6.242.728
java.lang.Object[] | 15.711 | 765.832 | 3.538.168
java.util.HashMap | 12.133 | 485.320 | 6.615.992
java.util.WeakHashMap$Entry | 8.593 | 343.720 | 1.007.144
java.lang.ref.WeakReference | 13.448 | 322.752 | 418.720
java.util.ArrayList | 9.115 | 218.760 | 1.178.712
java.util.Hashtable$Entry | 9.057 | 217.368 | 1.024.424
org.openide.util.WeakListenerImpl$ListenerReference| 5.399 | 172.768 | 173.784
java.util.WeakHashMap$Entry[] | 236 | 162.976 | 939.392
org.openide.filesystems.MultiFileObject | 2.561 | 143.416 | 1.487.080
com.sun.tools.javac.util.Name[] | 4 | 131.776 | 133.312
org.openide.util.WeakListenerImpl$ProxyListener | 3.876 | 124.032 | 265.824
java.util.Hashtable$Entry[] | 1.179 | 114.792 | 1.137.576
-------------------------------------------------------------------------------------------

Unknown said...

Sorry the table doesn't look good in the comments section

Anonymous said...

Always the same: Please.. if you use diagrams use them correct: This points out especially for the first bar chart. When one bar shows 24 Mbyte - the other 22,7 Mbyt you have to start the chart at zero to make the bars show what's really going on. There is only a little difference round about 5% or something like that. Your chart pretends that there is a really important difference so you have to use additionally words to make clear this isn't the fact. But what is a chart good for if it has to be described with words to make it a bit less misleading ?

Unknown said...

Hi anonymous,
Thx for the hint.
I think the text makes clear that this was not my intention.
The Image is served from Google docs directly. I suppose they changed the default behavior.
I configured it explicitly now to start a 0.

Regards,
Markus