Bug 170141 - 38s in SetUriExecutionAction
38s in SetUriExecutionAction
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: Code
6.x
All All
: P2 (vote)
: TBD
Assigned To: Denis Anisimov
issues@javaee
http://statistics.netbeans.org/except...
EXCEPTIONS_REPORT perf-profileme
:
: 171091 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-10 14:45 UTC by Exceptions Reporter
Modified: 2009-09-04 03:55 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (10.06 KB, bin/nps)
2009-08-10 14:45 UTC, Exceptions Reporter
Details
Relevant part of the back trace, hinting at a problem in web fragments (4.90 KB, text/plain)
2009-08-21 16:16 UTC, Petr Jiricka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2009-08-10 14:45:43 UTC
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
Comment 1 Exceptions Reporter 2009-08-10 14:45:48 UTC
Created attachment 86044 [details]
nps snapshot
Comment 2 Petr Jiricka 2009-08-21 16:16:22 UTC
Created attachment 86531 [details]
Relevant part of the back trace, hinting at a problem in web fragments
Comment 3 Petr Jiricka 2009-08-21 16:19:10 UTC
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.
Comment 4 Denis Anisimov 2009-08-27 18:51:31 UTC
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...
Comment 5 Petr Jiricka 2009-08-28 08:23:03 UTC
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.
Comment 6 Denis Anisimov 2009-08-28 17:07:02 UTC
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.
Comment 7 Denis Anisimov 2009-08-28 17:59:02 UTC
It seems original UI actions was org.netbeans.modules.web.project.ui.SetExecutionUriAction.
enable() method stack trace lead to getServlets() method of WebAppMetadataHelper.
Comment 8 Denis Anisimov 2009-08-28 18:20:39 UTC
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.
Comment 9 David Konecny 2009-08-30 22:51:04 UTC
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.
Comment 10 Denis Anisimov 2009-08-31 17:39:28 UTC
David, I'm going to do exactly the suggested thing.
Comment 11 Denis Anisimov 2009-08-31 18:27:01 UTC
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.
Comment 12 Denis Anisimov 2009-08-31 20:43:14 UTC
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.
Comment 13 Denis Anisimov 2009-09-03 16:08:42 UTC
*** Issue 171091 has been marked as a duplicate of this issue. ***
Comment 14 Quality Engineering 2009-09-04 03:55:44 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo