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 171331 - Find usages consumes too much memory
Summary: Find usages consumes too much memory
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jan Pokorsky
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 171188
  Show dependency tree
 
Reported: 2009-09-02 15:54 UTC by Jan Pokorsky
Modified: 2009-09-02 20:52 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
patch postponing creation of positions and data objects (7.71 KB, text/plain)
2009-09-02 16:40 UTC, Jan Pokorsky 		Details
patch not opening document (1.78 KB, patch)
2009-09-02 16:47 UTC, Jan Pokorsky 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Pokorsky 2009-09-02 15:54:15 UTC 
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. It is caused by computing document positions for each found
occurrence too early. I have created a patch not to load any Document and the test case takes about 30% of previous time
now.

See issue 171188 for the test case.
Comment 1 Jan Pokorsky 2009-09-02 16:40:59 UTC 
Created attachment 86981 [details]
patch postponing creation of positions and data objects
Comment 2 Jan Pokorsky 2009-09-02 16:47:37 UTC 
Created attachment 86982 [details]
patch not opening document
Comment 3 Jan Pokorsky 2009-09-02 16:52:35 UTC 
The second patch is less aggressive. It does not postpone creating of positions and data objects but ensures that any
document is not loaded. Times should be similar to 1. patch. Pavle could you measure it?
Comment 4 Pavel Flaska 2009-09-02 17:53:34 UTC 
Original data before patch:

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 5 Pavel Flaska 2009-09-02 17:56:25 UTC 
patch - default Mx - 48-64s.

Not only the time is dramatically shorter, but the testing machine is not overloaded with many GCs.
Comment 6 Jan Pokorsky 2009-09-02 20:52:39 UTC 
Great! Thank you. Fixed as jet-main 7545eb6e9ae0.