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 152491 - reduce peak of memory consumption
Summary: reduce peak of memory consumption
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Miloslav Metelka
Depends on: 121357 152969
Blocks: 152213 185586
  Show dependency tree
Reported: 2008-11-06 08:47 UTC by Alexander Simon
Modified: 2010-10-22 12:51 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Simon 2008-11-06 08:47:44 UTC
Class org.netbeans.lib.editor.util.GapList has an array as a element storage.
Last storage resizing consumes a lot of memory.
For example see related IZ#152213.
Last storage resizing consume more then 100M additional memory.
Make storage segmented for huge files.
Comment 1 Alexander Simon 2008-11-06 09:06:52 UTC
Excuse me, 100M is a size of objects in array.
Array consumes 13M.
Array has about 3M elements.
Comment 2 Miloslav Metelka 2008-11-06 13:02:07 UTC
GapList is used across many storages in editor. Can you tell me what are the members of the array so that I can figure
out what's going on? Does it happen with cnd or some other mimetype? Thanks.
Comment 3 Alexander Simon 2008-11-06 14:48:21 UTC
It happen in cnd.
For understanding:
Declaration included from generated header file that contains 300K lines.
User can go to declaration from user file.
IDE open header, consume about 800M memory in peak.
I see problems:
- no cache for attributes. I see 1M attributes sets.
- internal array in GapList has 3M elements. It too long to be not segmented.
Comment 4 Miloslav Metelka 2008-11-10 14:28:07 UTC
Downgrading to P3 since opening a file with 300K lines is IMHO not a common usecase. OTOH I agree that 800M (let's say
2.5K per line) is a lot so we should attempt to decrease the per-line ratio. The storage on the editor side could be
decreased (e.g. by a new view hierarchy - issue 121357) but I see no point of having an extra issue here - there are
already per-representing-structure issues entered. Reassigning to cnd to evaluate cnd-specific storages first (e.g.
parse trees being held etc.).
Regarding attribute sets there may be attribute sets with some special instance in them (e.g. a tooltip or annotation)
which makes them unsharable.
Regarding the 3M array I don't see any point of making it segmented. Could you please explain it? Having 300K lines and
3M tokens array means that there's about 10 tokens per line which is understandable. Btw the storage of tokens gets
trimmed after document loading automatically so there should be no extra unused space in the array.
Comment 5 Alexander Simon 2008-11-11 08:06:37 UTC
Memory distribution (retained size):
403M - all
148M - o.n.m.editor
127M - o.n.m.cnd
119M - o.n.spi.editor
94M - o.n.editor
41M - o.n.lib.editor
38M - o.n.lib.lexer
38M - o.n.api.editor
38M - o.n.api.lexer
Comment 6 Alexander Simon 2008-11-11 08:50:30 UTC
I see 1,162,508 instances of javax.swing.text.AttributeSet[] (28Mb).
I wonder why NB do not shared similar innstance of AttributeSet[].
Comment 7 Miloslav Metelka 2008-11-11 16:27:31 UTC
I've entered a separate issue 152969 for AttributeSet caching.
Comment 8 Vladimir Voskresensky 2009-09-25 13:45:22 UTC
editor responsibility
Comment 9 David Strupl 2010-10-22 08:30:32 UTC
Milo, can we mark 121357 as fixed?

And Alexandr I suggest to close this report or please post a new measurement and try to identify what should be improved now after Mila's new view hierarchy and Dusan's new formatting. After new data are available we can again create separate issues for the smaller parts that should be improved ...

BTW do we have an issue for removing the old syntax? Milo, Dusane, can this still be done for 7.0? I think I can work on that after I am back from next week vacation (if nobody else has done it already) ...
Comment 10 Alexander Simon 2010-10-22 10:33:12 UTC
I agree.
Comment 11 David Strupl 2010-10-22 12:51:47 UTC
Ok, I am closing this one and Milo please close 121357. Thanks.