This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Performance test reports there is a NetBeans startup regression which is caused by the loading of the following class: org.netbeans.modules.projectapi.Installer Please don't load this class during NetBeans startup. Comment from jtulach: "Move the code to some static { initializer(); }"
Created attachment 66712 [details] Stacktrace
what is the "regression" in hard numbers? Since jtulach suggested me to move the code to me when he saw the commit log, without any measurement at all, I assume you just act in his name. closing as invalid, until you prove the regression is significant enough to care.
Please take a look at the URL specified. The regression is caused by the fact that this class was not loaded before 06/25/2008 and it is being loaded since 07/07/2008, i. e. number of loaded classes incremented. If it replaced some other classes that are not longer loaded please let me know. I also found that this is somehow connected with issue 125582 jtulach, could you please comment on that?
please update your while list with the classes that were introduced to fix a bug. Unless you prove there's actual significant performance hit, I'm not going to make the code more complex and error prone. While you have your goals and metrics, I have mine too, sorry. BTW: how many classes are we talking about?
We are trying hard to eliminate all the unnecessary work that is being done during start. This includes primarily two directions: 1. change the infrastructure to be more scalable and do not require classes to be loaded on start. 2. search for places where a module initializes itself prematurely and find a way to delay initialization until it is really needed. Your case fails into the second category and in my opinion has easy fix. Moreover it is new code, functionality added recently, so the probability of functional regression against previous version is close to zero. That is why I want you to help us align code that you write with our scalability goals of not initializing anything that is not needed. I can imagine that this is not really big issue for NetBeans IDE, as projects will be initialized as soon as users start to work with them anyway. However I feel somewhat uneasy to have initialization in an autoload module which provides only APIs. This would mean that even applications that include this module to satisfy dependencies of other modules, would pay the penalty of this initialization. Please, move the initialization code to static initializer or provide justification why that cannot be done, e.g. what would be broken by doing it.
So you don't really have any numbers regarding the assumed performance hit, therefore I'm removing the PERFORMANCE keyword. It cannot be a REGRESSION as it was not present in old version (is new functionality introduced to fix a bug), removing the keyword as well. BTW, if a simple postRequest(Runnable) defeats your metric, I would say the metric is not worth much anyway.
HOW MANY CLASSES ARE WE TALKING ABOUT?
I was not able to understand why Miloš pushbacks so hard until Tomáš Pávek explained to me that the problem is not only in deserialization (which could easily be moved to static class initializer), but also serialization (which now happens in close). I can now, after getting this, confirm that the Miloš is right, close() is the right place to do the serialization. Now when we need Initializer for serialization, there is no problem in doing deserialization here as well. Alexander, please add this class to whitelist.
Added. changeset: 95550:5260fbc90063
Verified with 080811 Dev build
Integrated into 'main-golden', available in build *200808120201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/5260fbc90063 User: Alexander Kouznetsov <mrkam@netbeans.org> Log: Added 3 new classes to whitelist according to issues #143070 and #143065