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.
During the IDE startup, each of the .settings files under the Services folder will get parsed at least twice during the FolderLookup initialization. It is caused by this code in the core: SerialDataConvertor.java:73 if (isModuleEnabled()) { instance = createInstance(null); lkpContent.add(instance); } where in isModuleEnabled->getModuleInfo() is code to create/parse an instance: String module = new SettingsInstance(null).getSettings(true).getCodeNameBase(); and the parsed instance is immediatelly forgotten and created again from above mentioned instance = createInstance(null); and is parsed again later (on demand). It is possible to keep the parsed instance, which will significantly speed up the FolderLookup initialization.
I'm not sure whether this is a long-time behaviour or a regression. CCing Trung, he will certainly be interrested.
Can we measure how much time does one round of .settings parsing cost?
The difference in FolderLookup initialization on my machine was about 6100ms vs. 4800ms when I added side band for reusing the data parsed in getModuleInfo(). The parse() calls were reduced from 225 to 125 during the IDE startup. It is in par with one .settings file parsing cost of ~10ms the 2+ means some files are parsed three times, but the last parsing is IMO OK - it is the full parsing in case somebody wants the instance, while the first parsing is header-only parsing which breaks as soom as the needed headers are parsed. But there can still be some space for improvements.
You are right. There are up to 3 parsing cycles 1. parsed just header to find out MI 2. parsed just header to find out classes' names 3. parsed the whole file to be able to read a persisted object. ad 1) could be eliminated by sharing results in steps 1 and 2 ad 3) performed just in case someone calls InstanceCookie.instanceCreate and MI.isEnabled == true Definitely the step 1 is eliminated by using settings convertors. They do not need any MI at all and should be the prefered way to store settings now.
fixed in http://core.netbeans.org/source/browse/core/src/org/netbeans/core/projects/SerialDataConvertor.java.diff? r1=1.8&r2=1.9
Thanks. It have sped up the IDE startup on my machine by about 1.5s ;-)
I think this safe and benefical fix should be included in 3.4.1
Hi. This issue is marked as 3.4.1_CANDIDATE. It means that it should be integrated into release341 one branch. The plan at http://www.netbeans.org/devhome/docs/releases/34/index.html expected beta1 to be produced on Dec01. That did not happen due to a lot of outstanding not integrated candidates like this one. Would it be possible to spend few minutes by backporting this fix? Thank you in advance.
integrated to the release341 branch /cvs/core/src/org/netbeans/core/projects/SerialDataConvertor.java,v1.8.18.1
How can Version == 4.0 dev and Target Milestone == 3.4.1?? Please fix the Version field.
version changed to 3.4
How? Simple - the bug was reported against 4.0dev, but then discovered to be in 3.4 too, Was fixed in trunk and release341, hence Target Milestone is 3.4.1. The question is, whether we're supposed to backwards-search all the bugs, whether they are applicable to 3.3, 3.2, 0 or it's simply that Version must be <= than Target milestone you are opposing, Jesse?
Resolved for 3.4.x or earlier, no new info since then -> closing.