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 183289 - Memory usage should be optimized during execution of actions Find and Replace in files, projects, etc.
Summary: Memory usage should be optimized during execution of actions Find and Replace...
Status: RESOLVED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: Search (show other bugs)
Version: 6.x
Hardware: All All
: P2 normal (vote)
Assignee: Jaroslav Havlin
URL:
Keywords: PERFORMANCE
: 175991 178583 182123 205949 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-31 14:52 UTC by Victor Vasilyev
Modified: 2012-03-20 12:50 UTC (History)
26 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 161455


Attachments
stacktrace (2.13 KB, text/plain)
2010-04-16 08:16 UTC, schkovich
Details
stacktrace (2.47 KB, text/plain)
2010-04-16 10:22 UTC, Oleg Khokhlov
Details
stacktrace (3.08 KB, text/plain)
2010-08-20 12:59 UTC, Filip Zamboj
Details
stacktrace (941 bytes, text/plain)
2010-08-27 12:09 UTC, Filip Zamboj
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Vasilyev 2010-03-31 14:52:02 UTC
This bug report is intended to collecting of all randomly occurring negative incidents during execution of both actions Find and Replace in files, projects, etc. (but NOT in the Editor, i.e not Ctrl+F nor Ctrl+H !!!) that have a relation to memory consuming.

Currently, it is not clear where a causal place of the issues related to memory usage. I hope, consolidated review of all such incidents will give us ideas about possible ways and criteria for optimization of the implementation of the org.netbeans.modules.search package.

Although this bug is against to the utilities/search component, but it is possible that a causal place of the bug is outside of this component. 
Because:
* the component relies on the infrastructure of the NetBeans, including entities like FileObject, DataObject and so on.
* other services installed in the NetBeans IDE are also perform operations consuming memory when a user selects desired scope for searching. 

We need also take into account that the implementation stops searching if a limit of either matched text occurrences (i.e. 5000 occurrences) or files containing the matched text (i.e. 500 files) is reached.
Comment 1 Victor Vasilyev 2010-03-31 14:53:17 UTC
*** Bug 178583 has been marked as a duplicate of this bug. ***
Comment 2 Victor Vasilyev 2010-03-31 14:53:57 UTC
*** Bug 175991 has been marked as a duplicate of this bug. ***
Comment 3 Victor Vasilyev 2010-03-31 14:55:46 UTC
See also test results in the Bug 170545
Comment 4 Victor Vasilyev 2010-03-31 15:00:29 UTC
*** Bug 182123 has been marked as a duplicate of this bug. ***
Comment 5 schkovich 2010-04-16 08:16:49 UTC
Created attachment 97504 [details]
stacktrace

Renaming JavaScript variable
Comment 6 Oleg Khokhlov 2010-04-16 10:22:48 UTC
Created attachment 97513 [details]
stacktrace

there was profiling session inside profileMe
Comment 7 Victor Vasilyev 2010-04-17 20:54:13 UTC
(In reply to comment #5)
> Created an attachment (id=97504) [details]
> stacktrace
> 
> Renaming JavaScript variable

schkovich,
 
Seems this case doesn't have relation to actions Find or Replace.
If so then, please, file a separate bug against the component Refactoring here: http://netbeans.org/bugzilla/enter_bug.cgi?product=javascript
Comment 8 Victor Vasilyev 2010-04-20 13:39:35 UTC
(In reply to comment #6)
> Created an attachment (id=97513) [details]
> stacktrace
> 
> there was profiling session inside profileMe

Oleg,

This incident doesn't also have a relation to the Searching.
Please, file a separate bug against the profiler.

I'll change the bug title to be more specific.
Comment 9 schkovich 2010-04-20 14:41:00 UTC
(In reply to comment #7)
> (In reply to comment #5)
> > Created an attachment (id=97504) [details] [details]
> > stacktrace
> > 
> > Renaming JavaScript variable
> 
> schkovich,
> 
> Seems this case doesn't have relation to actions Find or Replace.
> If so then, please, file a separate bug against the component Refactoring here:
> http://netbeans.org/bugzilla/enter_bug.cgi?product=javascript

The problem is still present in Build 201004200200.

I will file the report against the Refactoring component as soon as I create CPU snapshot and respective heap dump.
Comment 10 Filip Zamboj 2010-08-20 12:59:44 UTC
Created attachment 101564 [details]
stacktrace

I opened Tools->Options while project scanning was in progress
Comment 11 Filip Zamboj 2010-08-27 12:09:38 UTC
Created attachment 101717 [details]
stacktrace

php project opened
Comment 12 Marian Mirilovic 2011-01-14 15:21:11 UTC
228 dups -> P1
Comment 13 Antonin Nebuzelsky 2011-01-28 14:47:37 UTC
The current number of reports in http://statistics.netbeans.org/exceptions/detail.do?id=161455 is 231.

Unfortunately stacktraces gathered through exception reporter for OOME are useless. A stacktrace of OOME only indicates there was a memory problem and that a random thread raised OutOfMemoryException because that thread was accidentally the one scheduled for execution at the moment when there happened to be no more heap space available. The thread is not the culprit of the memory problem.

Decreasing priority of this particular issue related to Search back to P3. It needs to be addressed in future, but it is not a P1 only because random reports are mapped to it by the exceptionreporter tool.

Users who navigate to this issue and realize they were not running Search, should file a separate bug against the component relevant to the functionality they were using when OOME was raised.
Comment 14 Marian Mirilovic 2011-02-18 14:02:11 UTC
Tonda, could you please add the note above into ER log, so users will see it once faced this issue again ? Thanks in advance.
Comment 15 Antonin Nebuzelsky 2011-03-15 13:27:21 UTC
Added the note to the exception report page.
Comment 16 Marian Mirilovic 2011-12-02 10:03:25 UTC
Almost a year old decision and no progress ;( ... We've got 59 new reports, also for 7.1 ! ... so all together 289 reports - at least P2
Comment 17 Jaroslav Havlin 2011-12-07 12:20:00 UTC
core-main/rev/9531f47fc19b

For simple patterns, the file is read line by line and pattern matching is performed only within individual lines. So only one line has to be held in memory. This also brings slightly better performance.

More complex patterns across several lines are still supported. The size of buffer for reading file data was limited, which can imply worse performance (file data can be read more than once), but OutOfMemoryErrors should appear only seldom.
Comment 18 Jaroslav Havlin 2011-12-07 12:45:41 UTC
*** Bug 205949 has been marked as a duplicate of this bug. ***
Comment 19 Quality Engineering 2011-12-08 12:10:45 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/9531f47fc19b
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #183289 - Memory usage should be optimized during execution of actions Find and Replace in files, projects, etc.
Comment 21 Quality Engineering 2012-02-09 02:37:33 UTC
Integrated into 'releases', will be available in build *201202082200* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/d3c1478e8037
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #183289 - Memory usage should be optimized during execution of actions Find and Replace in files, projects, etc.
(transplanted from 9531f47fc19b897b8d2d5f72ca4fc1bd71d8f7a7)
Comment 22 invented0 2012-03-03 16:58:01 UTC
The nested class "LineInfo" inside "org.netbeans.modules.search.LineReader.java" does not need to be a nonstatic member class, each instance of which will contain a superfluous reference to the nesting class, which wastes space and time.
Comment 23 Jaroslav Havlin 2012-03-16 12:41:13 UTC
http://hg.netbeans.org/core-main/rev/30fc0b63bb8e
Thank you very much. Fixed.
Comment 24 Quality Engineering 2012-03-20 12:50:35 UTC
Integrated into 'main-golden', will be available in build *201203200400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/30fc0b63bb8e
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #183289 - Nested class LineReader.LineInfo does not need to be a nonstatic member class