Talk:NetbinoxPerformance

Both Equinox and Felix support what folks call "reference" installs. This is done with a "reference" protocol handler.

So if you had code like this:

Bundle b = context.installBundle(
 "file:/mybundles/someBundle.jar");

Then the content of /mybundles/someBundle.jar is copied into the framework cache as you have observed. But you can simply add a "reference:" to the front of your file: URL to have both Equinox and Felix read and use the content of the bundle without copying it into their own cache.

Bundle b = context.installBundle(
 "reference:file:/mybundles/someBundle.jar");

On Equinox (and I think Felix) you can also use reference: URLs to install bundles with opaque location string:

URL reference = new URL(
 "reference:file:/mybundles/someBundle.jar");

Bundle b = context.installBundle(
 "mylocation", reference.openStream());

Care must be used when using reference installs. You must treat the path to the bundle content as owned by the framework as long as that bundle is installed in the framework. You are basically extending the framework cache out to some other path on your system.

Hope that Helps.

--Tom Watson 21:01, 2 April 2010 (CEST)

Could you clarify what is being run in the performance numbers you gave for Equinox vs. Netbinox?

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the netbinox case you have additional extensions to Equinox that help startup time by doing additional caching?

• JT: Right, the same set of bundles. In case of Netbinox with our own implementation of BundleFile

The way you stated "I am glad to report that recently we improved Netbinox so much that our testing application (together with some parts of NetBeans) starts faster than Equinox itself." it sounds as though your whole application starts faster than an empty Equinox framework. That is not what you meant, correct?

• JT: Fixed. Thanks.

--Tjwatson 21:12, 2 April 2010 (CEST)

One significant caveat is that some of the NB performance boost (especially on filesystems with poor disk cache implementations) comes from not even stat'ing module JAR files, only checking the timestamp on a .lastModified placeholder file. This more or less works in the case of NB only because all of our tooling, as well as our Auto Update feature, have been specifically modified to touch .lastModified whenever changing module JARs. If you are using some other tooling, you need to either delete this timestamp (and lose some speed) or change your tooling to match. If you forget, changes to modules are silently ignored, which is quite baffling for a novice developer.

--Jesse Glick 18:05, 7 April 2010 (CEST)