CacheForModularity
From APIDesign
(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...) |
(→General Solution) |
||
| (4 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| - | 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. | + | 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 until one creates [[cache]]s. [[Cache]]s for modular execution. |
=== Speed Up === | === Speed Up === | ||
| Line 33: | Line 33: | ||
This includes various improvements but one of the most significant is | This includes various improvements but one of the most significant is | ||
the '''resources cache''' - we are able to start [[NetBeans]] without opening or even | the '''resources cache''' - we are able to start [[NetBeans]] without opening or even | ||
| - | touching (m)any [[JAR]] files. | + | touching (m)any [[JAR]] files. Btw. there is a lot of them, [[NetBeans]] 6.7 contains 600 to 1000 of [[JAR]]s. |
=== Trust but Verify === | === Trust but Verify === | ||
| Line 91: | Line 91: | ||
bad optimization. | bad optimization. | ||
| - | Please note that if you start NetBeans for the second time without cleaning | + | Please note that if you start [[NetBeans]] for the second time without cleaning |
the filesystem caches, the start time is something like: | the filesystem caches, the start time is something like: | ||
<source lang="text"> | <source lang="text"> | ||
| Line 99: | Line 99: | ||
cold start matters. | cold start matters. | ||
| + | === General Solution === | ||
| + | |||
| + | The [[CacheForModularity]] has been backported to [[OSGi]] to form the fastest (in terms of [[startup]] time) container on the planet - [[Netbinox]]. | ||
I believe any [[module system]] could benefit from the same infrastructure, if there was a | I believe any [[module system]] could benefit from the same infrastructure, if there was a | ||
Current revision
Let me share with you few notes about our NetBeans experience with modularity and how it affects and relates to performance. As noted in one paragraph written while modularizing the Java SE, if one seeks faster execution, then more modularity is usually more harmful than helpful. Except until one creates caches. Caches for modular execution.
Contents |
Speed Up
The NetBeans IDE improved its cold start by 30% from 33s in version 6.0 to 19s in version 6.7:
| Release | Start w/o Project | 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. Btw. there is a lot of them, NetBeans 6.7 contains 600 to 1000 of JARs.
Trust but Verify
To see it on your own. Get NetBeans 6.7 full distribution, unzip and remove ergonomics1 directory (to prevent other optimizations).
# get NetBeans from http://www.netbeans.org/downloads/zip.html $ unzip netbeans-6.7-*.zip $ rm -r netbeans/ergonomics1
start (once is enough, few times is not going to hurt anyone) it so it creates its caches:
$ netbeans/bin/netbeans --userdir tmp/userdir.fake
now clean OS filesystem caches or just reboot to clean them. I use
$ echo 3 > /proc/sys/vm/drop_caches
on my Linux to clear them.
Start again, with logging enabled:
$ netbeans/bin/netbeans --userdir tmp/userdir.fake -J-Dorg.netbeans.log.startup=print -J-Dnetbeans.logger.console=true
It prints a lot of things, but the important point is when main window is shown:
@40522 - Window system loaded
Now remove the NetBeans classes cache:
$ rm tmp/userdir.fake/var/cache/all-resources.dat
Drop the OS filesystem caches and start once again:
$ netbeans/bin/netbeans --userdir tmp/userdir.fake -J-Dorg.netbeans.log.startup=print -J-Dnetbeans.logger.console=true @62673 - Window system loaded
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:
@4192 - Window system shown
so compared to those horrible 62s, this is nothing to worry about. Only the cold start matters.
General Solution
The CacheForModularity has been backported to OSGi to form the fastest (in terms of startup time) container on the planet - Netbinox.
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 details of our implementation:
<comments/>
Follow
