Talk:NetbinoxPerformance - Revision history

JaroslavTulach at 08:45, 1 September 2011

JaroslavTulach — Thu, 01 Sep 2011 08:45:31 GMT

←Older revision		Revision as of 08:45, 1 September 2011
Line 44:		Line 44:
	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?		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 fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[NetBeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.	+	*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized (I mean [[OSGi]]fied) application fully independent on [[Eclipse]] or [[NetBeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

	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?		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?

JaroslavTulach at 08:44, 1 September 2011

JaroslavTulach — Thu, 01 Sep 2011 08:44:28 GMT

←Older revision		Revision as of 08:44, 1 September 2011
Line 33:		Line 33:
	</div>		</div>

-	Thanks a lot for the advice, I'll give it a try tonight. It really works: [http://hg.netbeans.org/core-main/rev/02f681fc9f3b 02f681fc9f3b]. Thanks. I shall blog about ''improperly documented APIs'' ~~one day~~ - 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.	+	Thanks a lot for the advice, I'll give it a try tonight. It really works: [http://hg.netbeans.org/core-main/rev/02f681fc9f3b 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.

	--[[User:JaroslavTulach\|JaroslavTulach]] 19:50, 3 April 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 19:50, 3 April 2010 (UTC)

JaroslavTulach at 08:42, 1 September 2011

JaroslavTulach — Thu, 01 Sep 2011 08:42:54 GMT

←Older revision		Revision as of 08:42, 1 September 2011
Line 44:		Line 44:
	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?		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 fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[~~Netbeans~~]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.	+	*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[NetBeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

-	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?	+	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.		*JT: Fixed. Thanks.

JaroslavTulach at 08:42, 1 September 2011

JaroslavTulach — Thu, 01 Sep 2011 08:42:07 GMT

←Older revision		Revision as of 08:42, 1 September 2011
Line 40:		Line 40:

	<div class='commentBlock'>		<div class='commentBlock'>
-	Could you clarify what is being run in the performance numbers you gave for Equinox vs. Netbinox?	+	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?	+	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 <code>BundleFile</code>	+	*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[Netbeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

-	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?	+	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.		*JT: Fixed. Thanks.
Line 64:		Line 64:
	Of course with the ''reference:'' protocol, the [[JAR]]s 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.		Of course with the ''reference:'' protocol, the [[JAR]]s 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 [[JAR]]s (by touching the ''.lastModified'' file).	+	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 [[JAR]]s (by touching the ''.lastModified'' file). Which is what [[JDeveloper]] does.

	--[[User:JaroslavTulach\|JaroslavTulach]] 19:44, 8 April 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 19:44, 8 April 2010 (UTC)

JaroslavTulach at 19:44, 8 April 2010

JaroslavTulach — Thu, 08 Apr 2010 19:44:51 GMT

←Older revision		Revision as of 19:44, 8 April 2010
Line 64:		Line 64:
	Of course with the ''reference:'' protocol, the [[JAR]]s 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.		Of course with the ''reference:'' protocol, the [[JAR]]s 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 ~~avoid~~ command line tools to alter the [[JAR]]s (by touching the ''.lastModified'' file).	+	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 [[JAR]]s (by touching the ''.lastModified'' file).

	--[[User:JaroslavTulach\|JaroslavTulach]] 19:44, 8 April 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 19:44, 8 April 2010 (UTC)

JaroslavTulach at 19:44, 8 April 2010

JaroslavTulach — Thu, 08 Apr 2010 19:44:17 GMT

←Older revision		Revision as of 19:44, 8 April 2010
Line 59:		Line 59:
	--[http://wiki.netbeans.org/JesseGlick Jesse Glick] 18:05, 7 April 2010 (CEST)		--[http://wiki.netbeans.org/JesseGlick Jesse Glick] 18:05, 7 April 2010 (CEST)
	</div>		</div>
		+
		+	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 [[JAR]]s 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 avoid command line tools to alter the [[JAR]]s (by touching the ''.lastModified'' file).
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 19:44, 8 April 2010 (UTC)

76.19.97.127: Comment provided by Jesse Glick - via ArticleComments extension

76.19.97.127 — Wed, 07 Apr 2010 16:05:06 GMT

Comment provided by Jesse Glick - via ArticleComments extension

←Older revision		Revision as of 16:05, 7 April 2010
Line 51:		Line 51:

	--[[User:Tjwatson\|Tjwatson]] 21:12, 2 April 2010 (CEST)		--[[User:Tjwatson\|Tjwatson]] 21:12, 2 April 2010 (CEST)
		+	</div>
		+	== Jesse Glick said ... ==
		+
		+	<div class='commentBlock'>
		+	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.
		+
		+	--[http://wiki.netbeans.org/JesseGlick Jesse Glick] 18:05, 7 April 2010 (CEST)
	</div>		</div>

JaroslavTulach at 20:03, 3 April 2010

JaroslavTulach — Sat, 03 Apr 2010 20:03:41 GMT

←Older revision		Revision as of 20:03, 3 April 2010
Line 33:		Line 33:
	</div>		</div>

-	Thanks a lot for the advice, I'll give it a try tonight.	+	Thanks a lot for the advice, I'll give it a try tonight. It really works: [http://hg.netbeans.org/core-main/rev/02f681fc9f3b 02f681fc9f3b]. Thanks. I shall blog about ''improperly documented APIs'' one day - 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.

-	--[[User:JaroslavTulach\|JaroslavTulach]] 17:50, 3 April 2010 (UTC)	+	--[[User:JaroslavTulach\|JaroslavTulach]] 19:50, 3 April 2010 (UTC)

	== Tjwatson said ... ==		== Tjwatson said ... ==

JaroslavTulach at 17:50, 3 April 2010

JaroslavTulach — Sat, 03 Apr 2010 17:50:03 GMT

←Older revision		Revision as of 17:50, 3 April 2010
Line 32:		Line 32:
	--Tom Watson 21:01, 2 April 2010 (CEST)		--Tom Watson 21:01, 2 April 2010 (CEST)
	</div>		</div>
		+
		+	Thanks a lot for the advice, I'll give it a try tonight.
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 17:50, 3 April 2010 (UTC)
		+
	== Tjwatson said ... ==		== Tjwatson said ... ==

Line 38:		Line 43:

	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?		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 <code>BundleFile</code>

	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?		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.

	--[[User:Tjwatson\|Tjwatson]] 21:12, 2 April 2010 (CEST)		--[[User:Tjwatson\|Tjwatson]] 21:12, 2 April 2010 (CEST)
	</div>		</div>

Tjwatson: Comment provided by Tjwatson - via ArticleComments extension

Tjwatson — Fri, 02 Apr 2010 19:12:04 GMT

Comment provided by Tjwatson - via ArticleComments extension

←Older revision		Revision as of 19:12, 2 April 2010
Line 31:		Line 31:

	--Tom Watson 21:01, 2 April 2010 (CEST)		--Tom Watson 21:01, 2 April 2010 (CEST)
		+	</div>
		+	== Tjwatson said ... ==
		+
		+	<div class='commentBlock'>
		+	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?
		+
		+	--[[User:Tjwatson\|Tjwatson]] 21:12, 2 April 2010 (CEST)
	</div>		</div>