CacheForModularity

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(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...)
Current revision (08:57, 13 June 2011) (edit) (undo)
(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:

NetBeans IDE Speedup
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/>

Personal tools
buy