Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 171188 - Find usages very slow when thousands of usages
Find usages very slow when thousands of usages
Product: java
Classification: Unclassified
Component: Refactoring
All All
: P2 (vote)
: 6.x
Assigned To: Jan Pokorsky
Depends on: 171331 171652 171657
  Show dependency treegraph
Reported: 2009-08-31 15:55 UTC by Pavel Flaska
Modified: 2009-09-10 14:04 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Flaska 2009-08-31 15:55:50 UTC
When trying to find ~6000 usages of class, it takes minutes.

Here are data for comparison (project internally available at, Java Free Form).
Look for usages of DBObject class:

5.5 - 75-95s - Mx256m
6.5.1 - OOME, with Mx increased to 768M 50-65s
6.7.1 - 140-175s, with Mx increased to 768M 85-93s
trunk - 155-170s - default -Mx, in this case ~500M. (with Mx256m OutOfMemoryError), with Mx 768M 75-80s
eclipse galileo - 12-15s
Comment 1 vallej 2009-09-01 20:08:28 UTC
ohh, sorry, wrong issue
Comment 2 Jan Pokorsky 2009-09-02 16:38:55 UTC
There are involved several things. I will file separate issues for them and leave this issue as an umbrella.

Strange is the memory consumption at first look. Lack of memory slows down javac significantly. The thread dump analyzes
shows that there are many instances (~900000) of PositionBounds and other classes related to Document. See issue 171331
for more.
Comment 3 Jan Pokorsky 2009-09-07 17:38:41 UTC
Another place significantly slowing down the find usages seems to be WhereUsedElement.create which starts the java lexer
(issue 171652).
Comment 4 Jan Pokorsky 2009-09-07 18:17:58 UTC
In case of huge results (> 5000 occurrences) it is pretty slow to expand all nodes or switch physical/logical view and
it may even run out of memory (issue 171657).
Comment 5 Jan Pokorsky 2009-09-10 14:04:28 UTC
The last measure of find class usages shows 45-48s with default -Mx on the tested project. It is up to 4x faster in
comparison with previous releases. The node expansion runs 10x faster and the memory is not exhausted.  The most time is
consumed by javac attributing now. Faster times would be possible only with rewritten refactoring infrastructure (lazy
nodes, perform just parsing not attributing or .class file inspection) which is not doable for 6.8. I consider this as
fixed for NB 6.8.

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