Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!

Bug 144727

Summary: Find Usages is too slow
Product: java Reporter: twolf2919 <twolf2919>
Component: RefactoringAssignee: Jan Pokorsky <jpokorsky>
Status: RESOLVED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P3 CC: issues, issues
Version: 6.xKeywords: PERFORMANCE
Target Milestone: 6.x   
Hardware: All   
OS: All   
Whiteboard:
Issue Type: DEFECT Exception Report:
Attachments: Thread dump of Find Usages (on a package-private class).

Description twolf2919 2008-08-21 15:43:40 UTC
I'm running the 6.5 dailies and noticed that "Find Usages" takes way too long.  On my 3800 file J2SE project, spread
over 4 source roots, it consistently takes 40+ seconds (from the time I hit the "Find" button on the Find Usages dialog)
to present the results.  Out of those 40+ seconds, the first 20 seconds have no user feedback at all (other than the
greying out of the dialog).  Then, the progress bar appears and the words "Initializing Data..." above it.  Eventually,
the results show up.

GUI/Human factor design rules suggest not to leave a user without feedback for more than a couple seconds.

Specifics:
The "Find Usages" was on a public static method in a widely used base class.  But the method is not used that much - the
results only showed 26 instances.

Environment:
Dell Latitude D810 laptop (5400rpm disk), 2GB RAM, running Ubuntu 8.04.  JDK is 1.6b10 build 25.
Comment 1 matthies 2008-08-21 17:04:34 UTC
Just upgraded to 6.5, and yes, something is definitively wrong with Find Usages and related refactorings in 6.5, they 
are WAY too slow. In my standard group of projects, a simple Find Usages on a class (with only a small number of actual 
usages) takes over a minute where in 6.1 it took 2-3 seconds. This makes 6.5 unusable(!) for us.
Comment 2 matthies 2008-08-21 17:05:32 UTC
PS 6.5 = 6.5 Beta for me.
Comment 3 Peter Pis 2008-08-21 17:15:47 UTC
Reassigning to "refactoring" for evaluation.

Could you please attach thread dump.
http://wiki.netbeans.org/GenerateThreadDump
Comment 4 matthies 2008-08-21 17:44:19 UTC
Created attachment 68047 [details]
Thread dump of Find Usages (on a package-private class).
Comment 5 matthies 2008-08-21 17:46:47 UTC
I notice that during Find Usages there's stuff being done in org.netbeans.modules.groovy.refactoring although we don't 
use Groovy in our projects.
Comment 6 martin_adamek 2008-08-22 09:21:21 UTC
This is duplicate of issue 143851 which has been fixed in trunk already.

*** This issue has been marked as a duplicate of 143851 ***
Comment 7 matthies 2008-08-22 14:07:28 UTC
Verified as fixed in Build 200808220201.
Comment 8 twolf2919 2008-08-22 14:56:15 UTC
I'm re-opening this bug rather than the one this is marked a duplicate of, mainly because I didn't create that one, so I
don't know what its intent was.  I do know what the intent of this one was: performance.

I see that the latest daily I downloaded (08/22) does, indeed, improve the performance of my Find Usages case by nearly
50%: it was 40+ seconds - now it takes 24 seconds.

But my question is: is this the best you can do?  The identical "Find Usages" on Eclipse takes 6 seconds the first time
and when you do it again, it's smart enough to cache it and it takes 1 second.

Comment 9 twolf2919 2008-08-22 15:30:26 UTC
One quick followup: I wasn't quite being fair in the Eclipse/NB comparison: my colleague who uses Eclipse is running on
a pretty powerful desktop (Core 2 Duo with a 7200rpm SATA disk running XP, vs. my Latitude D810 laptop with a piddly
5400rpm disk, running Ubuntu 8.04).  But I think my argument is still valid - this difference in CPU/disk cannot account
for a 4-to-1 difference in speed.
Comment 10 Tomas Pavek 2008-08-22 17:00:46 UTC
Issue 143851 fixed likely the regression reported by matthies. Other improvements were done for 6.5, but we don't know 
how to make it 4 times faster right now. Could check with 6.1 just to get the idea how we compare in your case? The 
time really depends on concrete sources; and it is not really much about how many usages are found in the end, but how 
big amount of data needs to be searched through.
Comment 11 martin_adamek 2008-08-28 07:36:33 UTC
Reassigning back to refactoring, as reported problem in Groovy support was fixed.
Comment 12 Jan Becicka 2008-08-28 10:34:31 UTC
Pavel will do some measurements to be sure we didn't regress since 6.1
Comment 13 Pavel Flaska 2008-09-03 08:08:48 UTC
I do not see any regression in comparison with 6.1. I have tried to find usages in of a class and it takes the same time in 6.1 and 6.5.
Tested project has ~400 classes. Then I have tried to find usages of a static method of a widely used class. Again, I did not find any difference between 6.1 
and 6.5.

Removing regression keyword.

Comment 14 Pavel Flaska 2008-09-03 08:15:53 UTC
For next release, we think about using full identifier index. Such index will slowdown initial scanning little bit (8% in current prototype), but should 
dramatically help in original reported use-case.
Comment 15 Pavel Flaska 2008-09-03 08:18:25 UTC
Reassigned to Honza, he should be able to provide more details about the planned improvements.
Comment 16 Jan Pokorsky 2008-09-03 14:08:54 UTC
The origin problem was fixed, no other performance regression found thus closing as fixed. You can track improvements of
refactoring performance (especially find usages and rename) mentioned by pflaska in issue 120145.
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