'. '

Talk:NetbinoxPerformance

From APIDesign

Jump to: navigation, search

Comments on NetbinoxPerformance

Name (required):

Comment:


Tom Watson said ...

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)

Thanks a lot for the advice, I'll give it a try tonight. It really works: 02f681fc9f3b. Thanks. I shall blog about improperly documented APIs and MagicalStrings - the installBundle method does not mention this possibility at all. Thus I was seeking for another method like installBundleLocally, I could not imagine the same would be possible with different protocol.

--JaroslavTulach 19:50, 3 April 2010 (UTC)

Tjwatson said ...

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?

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)

Jesse Glick said ...

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)

The classical use of Equinox would copy all installed JAR bundles into private cache directory. It is my understanding that only Equinox itself can modify these caches. No external tools shall be doing that. As such it is even easier to use our caches in this scenario.

Of course with the reference: protocol, the JARs remain in their original locations and then nobody shall touch them. However (as has been said earlier in this discussion), with reference: protocol you need to threat the JAR as being owned by the OSGi container. No external tool can touch them anyway.

I have a feeling that the NetBeans .lastModified solution is on par with the reference: protocol, plus it defines an external contract to allow command line tools to alter the JARs (by touching the .lastModified file). Which is what JDeveloper does.

--JaroslavTulach 19:44, 8 April 2010 (UTC)

Personal tools