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
GUEST: Accessing the menus
Maximum slowness yet reported was 38921 ms, average is 38921
Created attachment 86044 [details]
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
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
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
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.
user: Denis Anisimov <email@example.com>
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)
User: Denis Anisimov <firstname.lastname@example.org>
Log: Fix for IZ#170141 - 38s in SetUriExecutionAction.
Method refreshFragments() removal.