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.
Summary: | [cat68] "Find usage" on Object methods extremely slow | ||
---|---|---|---|
Product: | java | Reporter: | larswestergren <larswestergren> |
Component: | Refactoring | Assignee: | Jan Becicka <jbecicka> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dstrupl, jbecicka, jpokorsky, kcr, matthies, vv159170 |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 199085 | ||
Bug Blocks: | 133914 | ||
Attachments: |
stacktrace
messages.log |
Description
larswestergren
2007-10-26 10:27:00 UTC
Please attach whole messages.log and do thread dump while CPU is at 100%. See http://wiki.netbeans.org/wiki/view/GenerateThreadDump Thanks Created attachment 51768 [details]
stacktrace
Created attachment 51769 [details]
messages.log
In fact it does not fail. It is incredibly slow. I fixed the problem with cancel. Now it really stops the CPU. Checking in RetoucheUtils.java; /cvs/refactoring/java/src/org/netbeans/modules/refactoring/java/RetoucheUtils.java,v <-- RetoucheUtils.java new revision: 1.39; previous revision: 1.38 done Checking in spi/JavaRefactoringPlugin.java; /cvs/refactoring/java/src/org/netbeans/modules/refactoring/java/spi/JavaRefactoringPlugin.java,v <-- JavaRefactoringPlugin.java new revision: 1.20; previous revision: 1.19 done 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(). 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 as Set<PROJECT_CLASSES>. Not for 6.0. *** Issue 123183 has been marked as a duplicate of this issue. *** I just ran into this bug as well. Any chance it will get fixed in the near future? Honzo, is there any recent improvements in this area? 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 this. *** Issue 139042 has been marked as a duplicate of this issue. *** *** Issue 142149 has been marked as a duplicate of this issue. *** I have found a way how to speed it up in refactoring.java module. I can collect all java.lang.Object subclasses in ~10 seconds unlike the present implementation that needs hours to do the same. Reassigning. Integrated into 'main-golden', will be available in build *200903060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/49062a40ba46 User: Jan Pokorsky <jpokorsky@netbeans.org> Log: #120145: improving performance of tasks that collect subclasses . 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. Perhaps slightly different test case than the original, but very slow. It is not extremely slow any more. |