New page: Let me share with you few notes about our NetBeans experience with modularity and how it affects and relates to performance. As noted in [[Modular_Java_SE#False_Expectations|on...
New page
Let me share with you few notes about our [[NetBeans]] experience with [[modularity]] and how it affects and relates to [[performance]]. As noted in [[Modular_Java_SE#False_Expectations|one paragraph]] written while [[Modular_Java_SE|modularizing the Java SE]], if one seeks faster execution, then more [[modularity]] is usually more harmful than helpful. Except one creates [[cache]]s. [[Cache]]s for modular execution.
=== Speed Up ===
The [[NetBeans]] IDE improved its cold start by 30% from '''33s''' in version 6.0 to '''19s'''
in version 6.7:
{| border="1"
|+ '''NetBeans IDE Speedup'''
! style="width:100" | Release
! style="width:100" | Start w/o Project
! style="width:100" | Start w/ Project
|-
! 6.0
! 33s
! 54s
|-
! 6.1
! 22s
! 26s
|-
! 6.5
! 20s
! 26s
|-
! 6.7
! 19s
! 23s
|-
|}
This includes various improvements but one of the most significant is
the '''resources cache''' - we are able to start [[NetBeans]] without opening or even
touching (m)any [[JAR]] files.
=== Trust but Verify ===
To see it on your own. Get [[NetBeans]] 6.7 full distribution, unzip and remove
ergonomics1 directory (to prevent other optimizations).
<source lang="bash">
# get NetBeans from http://www.netbeans.org/downloads/zip.html
$ unzip netbeans-6.7-*.zip
$ rm -r netbeans/ergonomics1
</source>
start (once is enough, few times is not going to hurt anyone) it so it creates
its caches:
<source lang="bash">
$ netbeans/bin/netbeans --userdir tmp/userdir.fake
</source>
now clean OS filesystem caches or just reboot to clean them. I use
<source lang="bash">
$ echo 3 > /proc/sys/vm/drop_caches
</source>
on my Linux to clear them.
Start again, with logging enabled:
<source lang="bash">
$ netbeans/bin/netbeans --userdir tmp/userdir.fake -J-Dorg.netbeans.log.startup=print -J-Dnetbeans.logger.console=true
</source>
It prints a lot of things, but the important point is when main window is
shown:
<source lang="text">
@40522 - Window system loaded
</source>
Now remove the NetBeans classes cache:
<source lang="bash">
$ rm tmp/userdir.fake/var/cache/all-resources.dat
</source>
Drop the OS filesystem caches and start once again:
<source lang="bash">
$ netbeans/bin/netbeans --userdir
tmp/userdir.fake -J-Dorg.netbeans.log.startup=print -J-Dnetbeans.logger.console=true
@62673 - Window system loaded
</source>
I have guided you though all this exercise to show that the single trick of
not touching (m)any files on disk (you can verify with strace .. 2>&1 | grep
open for example) can greatly speed up time to start of (desktop) modular
application.
More than '''30%''' of time gained just by storing the classes needed during start
in a single file and not touching hundreds of small module files, is not that
bad optimization.
Please note that if you start NetBeans for the second time without cleaning
the filesystem caches, the start time is something like:
<source lang="text">
@4192 - Window system shown
</source>
so compared to those horrible 62s, this is nothing to worry about. Only the
cold start matters.
I believe any [[module system]] could benefit from the same infrastructure, if there was a
all-resources.dat cache for every started (desktop) application. I really
mean application, I don't mean [[module]] or [[JAR]]. The important point is to not
touch any files at all, except the all-resources.dat.
In case of owning [[HotSpot]], this could be combined
with caching not .class files, but their internal [[HotSpot]] representation. Then the result might get even better.
=== Technical Details ===
Here are links to [http://wiki.netbeans.org/StartupCache details of our implementation]:
* [http://hg.netbeans.org/main-golden/file/ae0c39ea7b80/o.n.bootstrap/src/org/netbeans/Archive.java Archive.java]
* [http://hg.netbeans.org/main-golden/file/ae0c39ea7b80/o.n.bootstrap/src/org/netbeans/JarClassLoader.java JarClassLoader.java]
<comments/>
[[Category:APIDesignPatterns:Performance]]