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: | Memory usage should be optimized during execution of actions Find and Replace in files, projects, etc. | ||
---|---|---|---|
Product: | utilities | Reporter: | Victor Vasilyev <vvg> |
Component: | Search | Assignee: | Jaroslav Havlin <jhavlin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexey_vasilyev, altosch, anebuzelsky, dominicjr, epdv, felipbou, FrantaM, fzamboj, gfronza, imc, jestep, kharezlak, lightalloy, mcseemz, mklaehn, mmirilovic, Mondane, mpapamichael, ovk, schkovich, Simmol, talofo, teknoid, troodon, ukko, XVilka |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 161455 |
Attachments: |
stacktrace
stacktrace stacktrace stacktrace |
Description
Victor Vasilyev
2010-03-31 14:52:02 UTC
*** Bug 178583 has been marked as a duplicate of this bug. *** *** Bug 175991 has been marked as a duplicate of this bug. *** See also test results in the Bug 170545 *** Bug 182123 has been marked as a duplicate of this bug. *** Created attachment 97504 [details]
stacktrace
Renaming JavaScript variable
Created attachment 97513 [details]
stacktrace
there was profiling session inside profileMe
(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 (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. (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. Created attachment 101564 [details]
stacktrace
I opened Tools->Options while project scanning was in progress
Created attachment 101717 [details]
stacktrace
php project opened
228 dups -> P1 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. Tonda, could you please add the note above into ER log, so users will see it once faced this issue again ? Thanks in advance. Added the note to the exception report page. 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 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. *** Bug 205949 has been marked as a duplicate of this bug. *** 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. Transplanted to releases. http://hg.netbeans.org/releases/rev/d3c1478e8037 http://hg.netbeans.org/releases/rev/9dfa8cf0bc63 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) 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. http://hg.netbeans.org/core-main/rev/30fc0b63bb8e Thank you very much. Fixed. 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 |