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.
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.
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.
PS 6.5 = 6.5 Beta for me.
Reassigning to "refactoring" for evaluation. Could you please attach thread dump. http://wiki.netbeans.org/GenerateThreadDump
Created attachment 68047 [details] Thread dump of Find Usages (on a package-private class).
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.
This is duplicate of issue 143851 which has been fixed in trunk already. *** This issue has been marked as a duplicate of 143851 ***
Verified as fixed in Build 200808220201.
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.
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.
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.
Reassigning back to refactoring, as reported problem in Groovy support was fixed.
Pavel will do some measurements to be sure we didn't regress since 6.1
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.
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.
Reassigned to Honza, he should be able to provide more details about the planned improvements.
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.