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.
Excuse me, 100M is a size of objects in array.
Array consumes 13M.
Array has about 3M elements.
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.
It happen in cnd.
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.
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.
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
I see 1,162,508 instances of javax.swing.text.AttributeSet (28Mb).
I wonder why NB do not shared similar innstance of AttributeSet.
I've entered a separate issue 152969 for AttributeSet caching.
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) ...
Ok, I am closing this one and Milo please close 121357. Thanks.