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.
Build: NetBeans IDE Dev (Build 200908022240) VM: Java HotSpot(TM) Client VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03 OS: Windows XP, 5.1, x86 User Comments: GUEST: Accessing the menus Maximum slowness yet reported was 38921 ms, average is 38921
Created attachment 86044 [details] nps snapshot
Created attachment 86531 [details] Relevant part of the back trace, hinting at a problem in web fragments
Looking at this issue, and issue 170098, I am thinking whether it would make sense to create an index for fragment files, and utilize the Parsing/Indexing infrastructure to store locations of fragments during scanning. This could significantly speed up the fragment computation.
How can I reproduce this issue ? I will need to check result of code modification . Also one will need to verify this issue... Petr, probably I don't exactly understand your suggestion about indexing. Could you please clarify your suggestion ? Please consider my thoughts about this . These are facts: - Annotated classes search is performed on first access to appropriate elements. - PeristentObjectManager stores references to objects which represent annotated classes after first search is performed. - On following access to elements they are retrieved from PeristentObjectManager's storage. - PeristentObjectManager changes stored references on java type change event ( if it has relation to stored object ). ( this is not applicable for annotated fields and methods ) So PeristentObjectManager actually performs something like memory "indexing" of annotated objects. I don't see here the place where we can use indexing for speeding up . But probably I missed such place. I see one possible problem at this issue ( not 170098 ): method refreshFragments() execution on each access to model elements. Probably it can be a problem but I'm not sure. In my case JSF merged model implementation models are refreshed only when file modification event appears. But JSF XML models are XAM/XDM based models and their refreshing probably is not so expensive. I need to investigate source code deeply...
My suggestion was to use the IDE's initial scan and store the location of web fragments in the index. The advantage could potentially be that we would utilize the file crawling that happens anyway (thus reducing IO) and that the locations would be remembered across IDE sessions. But I did not investigate deeply, so am not sure how significant improvement that would be. Also in this case, the IDE may need to check in some situations whether the scan is in progress, and potentially display a "please wait, scan is in progress" message in the UI.
I still need the way of reproduce. Otherwise all efforts to improve are just theoretical. >to use the IDE's initial scan Is there any API for such initial scan ? Probably I don't have knowledge in this area. Anyway initial scan could be run via calling Metadata Model methods. As result PersistentObjectManager will store in memory references to annotated objects. This is like indexing. We just need to be sure that there is no NEW reading of information about annotated objects on each metamodel method call. If so then this is the problem that should be mandatory fixed . The advantage of indexing in this situation is only saving information across sessions. Disadvantage of such approach is possible wrong indexing data. Such data could be not up-to-date after IDE new session start . One need to investigate this deeply. But there should be scenario which could be used for reproduction.
It seems original UI actions was org.netbeans.modules.web.project.ui.SetExecutionUriAction. enable() method stack trace lead to getServlets() method of WebAppMetadataHelper.
After further investigation I see that there is a problem at least in refreshFragments() method. It looks very strange for me. This method is called on every metamodel method call . Each time this method access to XML files inside Jar files and check their modification time. It seems this is resource consuming task. Probably this place has the most model access time (so annotation scanning could be not a problem at all) . ( one need to extract MANY files on each method invocation ). Modification time check for files inside Jar should be replaced to modification time check of Jar file itself. Other way : don't check modification time at all. There is possibility to add listener to filesystem . This listener could update WebApp ( WebFragment, main WebApp ) when Jar file is changed. As result refreshFragments() method is not needed and it will not be called on each model access. I will try to experiment with this suggestion when I find a way to reproduce this issue.
RE. "refreshFragments() method" - it does look strange. As it is scanning COMPILE classpath it should perform the scan once and then start listening on changes in COMPILE classpath and only rescan classpath after a change. RE. "problem reproduction" - I would try to place 20-40 jars on project's classpath (eg. all jars from glassfish) and add two or three jars which would have web-fragment.xml and see what happens.
David, I'm going to do exactly the suggested thing.
I haven't realized performance issues with various jar files number . So this issue was discovered under some special conditions which still needs to be described for verification. As result of investigation : we agreed with David that "refreshFragments()" method is a problem anyway. I will fix this problem at least.
Method "refreshFragments()" is removed. Listener to "compile" classpath is added. Now model is updated only on change event. It doesn't read jar files in classpath on each model access. Mark issue as FIXED. Probably there could be more improvements but they could be introduced after verification current state. changeset: 143285:553e290b4ca3 tag: tip user: Denis Anisimov <ads@netbeans.org> date: Mon Aug 31 23:40:23 2009 +0400 summary: Fix for IZ#170141 - 38s in SetUriExecutionAction.
*** Issue 171091 has been marked as a duplicate of this issue. ***
Integrated into 'main-golden', will be available in build *200909032054* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/553e290b4ca3 User: Denis Anisimov <ads@netbeans.org> Log: Fix for IZ#170141 - 38s in SetUriExecutionAction. Method refreshFragments() removal.