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.
JsfJavaDataLoader does file hierarchy traversal and project.xml's parsing for each recognized file. It means that during folder opening, the project file is parsed many times, contributing heavily to the UI responsiveness of the IDE. Folder traversal is also nontrivial contribution, when done many times. If you need to recognize project type this way during file recognition, you could cache the result of the check based on the first parent folder, so it will be done only once for given opened folder.
Visual Web already cached the 'project folder'. There is no reparsing of the project.xml file. I.e., For every project, there is only one 'single' parse for all the files inside an individual project! Are you sure you still seeing this parsing many times? Please see org.netbeans.modules.visualweb.project.jsf.api.JsfProjectUtils.isJsfProjectFile(FileObject), the first step it does is to looking at the cache isJsfProjectDir. And this has been filed/fixed/verified by issue#111029. *** This issue has been marked as a duplicate of 111029 ***
You're right, I see the parsing only once. But the parent folder traversal and project.xml localization is there many many times and these are in turn more expensive than the parsing. Also, you could probably replace the full XML parse with simple string matching, as is done in similar case for the Mobility's J2MEDataLoader
Quy, could you please evaluate this performance? I don't think the parent folder traversal is expensive unless there are hundreds of them, but looks like it's not. I also don't think one single xml parsing per project is expensive neither, scanning some special string looks dangerous to me! If we really need to do something here, then please reassign back to me. Thanks!
Created attachment 49960 [details] netbeans profiler snapshot
I've attached an NB profiler snapshot showing the execution times of JsfJavaDataLoader.findPrimaryFile() during the opening of a visual web project and several of its source folders. It does appear that the JsfProjectUtils.isJsfProjectFile() method takes some time (through the FileObject.getFileObject() method) as well as JsfProjectUtils.getJspForJava(). The caching for these methods could probably be more aggressive, so re-assigning to Po-Ting for a possible fix.
Quy, I don't have resource to looks at the .nps file (is it from JProfiler?). Could you please attach some data in pure text form? Thanks!
That's the NetBeans profiler snapshot. Just open in the IDE using either File->Open or Profiler->Open snapshot.
Here is another snapshot showing the opening of a package node in a java project containing 100 java source files. Most of the execution time (~90%) is in JsfProjectUtils.isJsfProjectFile().
Created attachment 50040 [details] nb profiler snapshot (jsfloader in java project)
Quy, I have done one partial fix for method isJsfProjectFile(), it now caches all directories inside a project instead of just the root directory. This will eliminate the parent folder traversal time. It should make both the getFileObject and getParent calls to the minimum. Could you please verify it? /cvs/visualweb/project/jsf/src/org/netbeans/modules/visualweb/project/jsf/api/JsfProjectUtils.java,v <-- JsfProjectUtils.java new revision: 1.49; previous revision: 1.48
The performance issue related to folder traversal appears to have been resolved. The calls to FileObject.getFileObject() and FileObject.getParent() changed as follows on a java package with 100 source files: FileObject.getFileObject() (# of calls): Before: 402 calls After: 6 calls FileObject.getParent() (# of calls): Before: 300 calls After: 102 calls
Replace the full XML and Property parse with simple string matching to improve performance. Quy, could you please verify the performance again? Thanks! /cvs/visualweb/project/jsf/src/org/netbeans/modules/visualweb/project/jsf/api/JsfProjectUtils.java,v <-- JsfProjectUtils.java new revision: 1.50; previous revision: 1.49
The parsing change seems to have improved the performance. I think the issue submitter should verify that the issue blocked by this one is resolved by these changes.
Much better now under the profiler. Still incurs some penalty, but that's the data systems problem in general.