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.
dev build from Oct 13, JDK 1.5.0 J2SEProject.ProjectOpenedHookImpl asks for computing of CRC32 checksums for project build files. Unfortunately we do it more times than neceseary for some files. stylesheets for generating of build.xml and build-impl.xml files are generated with each project. Maybe we do not need to compute this at all and just maintain some version numbers for stylesheet as it evolves. nbproject/project.xml is checked twice for each project - once with nbproject/build-impl.xml and then with build.xml file (J2SEProject.java lines 342 and 345).
Could avoid double-checking CRC for project.xml, probably. Re. version numbers for stylesheets - I initially planned that, but figured that in practice developers would forget to update them. The current approach seems safer. Lowering to P4 in lieu of evidence that CRC calculation is a major contribution to project opening time relative to other factors. When profiling the project open sequence I have never seen it as a major factor.
Not specific to j2seproject's, but to GeneratedFilesHelper.
Re. stylesheet CRC computation: if necessary, may be feasible to cache the CRC within a session for a given jar: URL. Needs to be subtle to handle module reloading - has to check the timestamp of the JAR file.
P4 is OK. You could see it if you tested on Ultra60 with sampling every 1ms ;-). Computing CRC for XML files is not a long operation (the first I/O is important but we need to read them anyway). Stylesheet check always takes 10 (/org/netbeans/modules/java/j2seproject/resources/build.xsl) - 25ms (/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl) on my Dell notebook.
Well 25ms is significant, esp. if it is repeated. I will see if some caching is feasible.
Wrote an in-memory CRC32 cache. It is keyed off of URL but only considered a cache hit if the timestamp and size of the requested file (or containing JAR) match those of the previous computation. So cache should be correct so long as either timestamp is changed or size is changed.
Radim could you check if that helps a little? added * Up-To-Date 1.1 ant/project/src/org/netbeans/spi/project/support/ant/Bundle.properties committed * Up-To-Date 1.10 ant/project/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java
I tested it with two projects open and the changed saved >20% of time spent in GeneratedFilesHelper$3.run (time decreased from 250ms to 190ms on my Solaris). It should be more beneficial with more projects. Thanks.