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.
Creating new "Basic Java Application" project takes over 10sec for the first time, about 2.5sec consecutively (when everything is initialized). Desired time is 2s/1s. [prj40_prototype build 200305230000, jdk 1.4.1_02, Win2000, PC 733 MHz]
Attaching profiling snapshots done in OptimizeIt.
Created attachment 10502 [details] profiling snapshot of 1st project creation; "sampler" method
Created attachment 10503 [details] profiling snapshot of subsequent project creation; "sampler" method
Created attachment 10504 [details] classes loaded during the first project creation
Note the measuring and profiling was done between pressing Finish button in the New wizard and showing the new project in Explorer.
Rough analysis reveals that the 1st creation is affected by heavy class loading and initialization - of projects, java module, and editor (almost 1000 classes loaded). We should try to eliminate this, do things more lazily. Note if just "Empty Java Application" project is created - which does not contain any java file - the time is less than half. The subsequent project creation needs further analysis, mainly the project instantiation, and also the visual update of Explorer.
There seems to be several things controbuting to the poor performance of project creation. ad 1. Useless copy of project template attributes - projects infrastructure allows to have several 'additional' attributes on project template files for variouse purposes. Since these attributes aren't 'known' for the FileUtil.copyFile method they are copied to the target project file during the template instantiation (this may also include serialization of WizardIterator objects, etc.) ad 2. Project file is parsed twice during the project open operation. ad 3. FileObject fileset excesively converts added links back and forth to detect whether they are broken or not. This affects e.g. compilation of java files, but also their visualization, because the isUpToDate method delegates to compiler. Also some caching in FileObject filesets could speed up accessing their contents. In general any call to FileUtil.fromFile seems to be expensive. ad 4. The Project.find should be optimized for FileObjects from ProjectFileSystem. It affects creation of lots of instances registered in natures. ad 5. The ConfigurationManager should cache results of getSettingsType calls, they are quite frequent and accessing layers through InstanceDataObject is overkill. New Registry API with properly handled bindings of primitive types also will help here. ad 6. The biggest part of project open operation is spent by JavaProject initialization like reading CompilationUnits and Classpath. This should be further investigated. I am going to file separate issues for #1 - #5 leaving this open for ivestigation of #6. Sidenote: Tomas, starting the java parser doesn't affect directly the project creation IMO, because the parser runs in another thread. However, making the CPU busy by parsing java sources created by the new project can of course slow down the project creation.
Filed: issue #34253 (#1), issue #34254 (#2), issue #34255 (#3), issue #34256 (#4), issue #34257 (#5)
The projects prototype has been canceled. For more details see http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss