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.

Bug 120145 - [cat68] "Find usage" on Object methods extremely slow
Summary: [cat68] "Find usage" on Object methods extremely slow
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jan Becicka
: 123183 139042 142149 (view as bug list)
Depends on: 199085
Blocks: 133914
  Show dependency tree
Reported: 2007-10-26 10:26 UTC by larswestergren
Modified: 2011-06-01 14:07 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

stacktrace (22.87 KB, text/plain)
2007-10-26 10:43 UTC, larswestergren
messages.log (50.77 KB, text/plain)
2007-10-26 10:45 UTC, larswestergren

Note You need to log in before you can comment on or make changes to this bug.
Description larswestergren 2007-10-26 10:27:00 UTC
Right clicking on methods such as clone() or toString() in any class that implements them, then selecting "Find usages",
the clicking "Find" button, causes Netbeans6.0Beta2 CPU usage to spike to 100% according to "top" (normal finds are
30-40% on my machine). The progress bar never pops up in the search window, and the find never finishes.

Pressing the "cancel" button causes the search window to disappear, but CPU usage remains high according to top and
jconsole so the search thread is obviously still busy spinning madly. Worse, right clicking anywhere in the editor
window for that or any other class after this has occured causes Netbeans to hang completely (no redraw), and it must be
killed from console. Same thing with closing Netbeans after cancelling the problematic find, the Netbeans process still
remains and must be killed manually.

I had been adding @Override annotation to methods, and it was after doing "Find usages" on one of them that I found this
bug. Removing the annotation did not change anything though.

The following I found in the log, but I don't know if it is related.

INFO [org.netbeans.core.ui.warmup.DiagnosticTask]: Total memory 1 591 296 000
WARNING []: findAnnotations: could not
find type javax.persistence.Entity
WARNING []: findAnnotations: could not
find type javax.persistence.Embeddable
WARNING []: findAnnotations: could not
find type javax.persistence.MappedSuperclass
WARNING [org.openide.loaders]: Please attach following information to the issue
<>: act
ion org.netbeans.modules.uml.integration.netbeans.actions.ReverseEngineerAction does not implement
SystemAction.getName() or Action.getValue(NAME) properly. It returns null!
Comment 1 Jan Becicka 2007-10-26 10:37:44 UTC
Please attach whole messages.log and do thread dump while CPU is at 100%. 
Comment 2 larswestergren 2007-10-26 10:43:30 UTC
Created attachment 51768 [details]
Comment 3 larswestergren 2007-10-26 10:45:30 UTC
Created attachment 51769 [details]
Comment 4 Jan Becicka 2007-10-26 12:35:29 UTC
In fact it does not fail. It is incredibly slow. I fixed the problem with cancel. Now it really stops the CPU.

Checking in;
/cvs/refactoring/java/src/org/netbeans/modules/refactoring/java/,v  <--
new revision: 1.39; previous revision: 1.38
Checking in spi/;
/cvs/refactoring/java/src/org/netbeans/modules/refactoring/java/spi/,v  <--
new revision: 1.20; previous revision: 1.19

The real problem is missing ClassIndex.SearchKind.IMPLEMENTORS_RECUSRIVE. I have my own impl at
RetoucheUtils.getImplementorsAsHandles().  This issue was caused by fix of issue 118102.

Problem is, that find all methods, which overrides or implements given method in current project is not efficient. I
must find all sublclasses, than their subclasses etc.. and it is really slow in case of toString().

Comment 5 Tomas Zezula 2007-10-26 12:57:15 UTC
Even in case the ClassIndex gives you list of recursive subclasses it will be slow in this case since everyone inherits
from j.l.Object. There are two possible solutions:
1) Build index on method level rather than on Class level -> index will directly know who overrides the j.l.Object.toString
2) Index on the class level + index of idents as in NB 5.x -> will not be very fast in this case either you will
need to parse nearly all since
Set<PROJECT_CLASSES>.retainAll(allInheritedFromObject).retainAll(files_which_contain_toString) will be nearly the same

Not for 6.0.
Comment 6 Jan Becicka 2007-12-03 15:54:12 UTC
*** Issue 123183 has been marked as a duplicate of this issue. ***
Comment 7 kcr 2008-01-04 22:50:58 UTC
I just ran into this bug as well. Any chance it will get fixed in the near future?
Comment 8 Jan Becicka 2008-07-23 10:59:23 UTC
Honzo, is there any recent improvements in this area?
Comment 9 Jan Pokorsky 2008-07-23 15:08:47 UTC
AFAIK Tomas has been working on some improvements of ClassIndex. In NB 6.5 the index should contain all declarations of
class members but I am not aware of any API through which the refactoring could access it. This would help in case of
searching for all overriding methods of j.l.Object.

For plain usages of Object's methods we would need full index that is in stage of prototype. tzezula should know more on
Comment 10 Jan Pokorsky 2008-07-29 13:33:42 UTC
*** Issue 139042 has been marked as a duplicate of this issue. ***
Comment 11 Jan Pokorsky 2008-07-30 11:58:28 UTC
*** Issue 142149 has been marked as a duplicate of this issue. ***
Comment 12 Jan Pokorsky 2009-03-05 15:03:56 UTC
I have found a way how to speed it up in module. I can collect all java.lang.Object subclasses in ~10
seconds unlike the present implementation that needs hours to do the same. Reassigning.
Comment 13 Quality Engineering 2009-03-06 09:17:30 UTC
Integrated into 'main-golden', will be available in build *200903060201* on (upload may still be in progress)
User: Jan Pokorsky <>
Log: #120145: improving performance of tasks that collect subclasses
Comment 14 David Strupl 2009-05-11 14:53:42 UTC
Comment 15 matthies 2009-10-27 19:24:40 UTC
Still extremely slow in 6.8 Beta.
Searched for usages of clone() in a project group which contains only very few usages of clone(), had to cancel it 
after ten minutes (it was still "initializing data"). It's pretty much unusable on larger projects.
Comment 16 Pavel Flaska 2009-11-02 10:35:11 UTC
Perhaps slightly different test case than the original, but very slow.
Comment 17 Jan Becicka 2010-10-06 13:52:34 UTC
It is not extremely slow any more.