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.
Test and implement some suitable pre-initializing task that would improve first-usage responsiveness of operations that use java module support. For more details about warm-up and preinitialization see issue 28591 and http://www.netbeans.org/servlets/ReadMsg?msgId=395924&listName=nbdev See also issue 28595 that deals with preinitialization in editor. In java module, most suitable areas that could benefit from preinitialization are: - expanding folders in Explorer (issue 27777), - opening java file in editor (issue 27710). I've already hacked some code for the second case. See branch warmup_40, files: /cvs/java/src/org/netbeans/modules/java/JavaWarmUpTask.java /cvs/java/src/org/netbeans/modules/java/resources/mf-layer.xml However, this is still an experiment, with detailed knowledge of the module I believe more effective preinitialization could be done. The most important problems of first usage (so good candidates for preinitialization) are: - classes loading (about 50% of whole time), - loading module settings. Especially pre-loading some classes saves much time in first folder expansion (from ~1600 ms to less than 300 ms in a textcase). The problem is how to make the classes to be loaded and resolved without loading them explicitly by name (or how to make such a code reasonably manageable). Other realization problems: - there is a big danger of deadlock, as the preinitialization runs in separate thread in different concurrent conditions than normally (all invoked operations must be thread safe), - the task itself should not run (or run very quickly) if not needed (i.e. IDE restores in such state when everything is already loaded/initialized).
Probably crazy, but I wonder if some further optimization could be done by specifying specific events which should trigger background loading of specific groups of classes. Issue 28623 (classloading when New menu is invoked) is an example; if modules could register classes (.instance files?) that should be loaded and post an event to a background loader, we could have warm-up without impacting startup time. For example, the Java module loads boatloads of stuff when you bring up the New menu/wizard and open one of its folders. If background loading could be triggered by choosing New or bringing up the wizard, probably the needed classes would be loaded by the time the user navigated the tree to, say, the Beans folder. The main issue would be making sure loading happened at very low priority or when the user was guaranteed to be reading something (like the template tree).
Please optimize also to correct negative effect of issue 28623. Probably the best warm-up task would be to simulate opening folder with a java file and parsing that java file. Something like I tried in the experiment (obtained nodes of java templates - but this won't work due to issue 28623 anymore).
Tim don't forget to add yourself as a CC when adding a comment... see Tomas's last comment. Note that a "low priority" task to recognize a data object is not possible, since this happens in the folder recognizer thread, not the calling thread.
Created attachment 9046 [details] Warmup patch for QA testing
I have attached a patch for QA testing; please unzip the file in NB's installation directory. It should work in dev builds or a recent Q-build.
I've just tried it and seen measurable improvements in New wizard <Next> panel invocation (is 1 sec now), first folder expansion (now 0.4 sec) and first file opening (now 1.6 sec). Had no problems (about 10 starts).
I've tried play with this patch and I haven't found any problems (10 starts, open files, restart IDE, new from template, popup). Svata, please merge patch to the trunk, thanks in advance.
Done in trunk: /cvs/java/src/org/netbeans/modules/java/JavaWarmUpTask.java,v <-- JavaWarmUpTask.java new revision: 1.2; previous revision: 1.1 /cvs/java/src/org/netbeans/modules/java/resources/mf-layer.xml,v <-- mf-layer.xml new revision: 1.39; previous revision: 1.38