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: | reduce peak of memory consumption | ||
---|---|---|---|
Product: | editor | Reporter: | Alexander Simon <alexvsimon> |
Component: | -- Other -- | Assignee: | Miloslav Metelka <mmetelka> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dbalek, dstrupl, issues |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 121357, 152969 | ||
Bug Blocks: | 152213, 185586 |
Description
Alexander Simon
2008-11-06 08:47:44 UTC
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. 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. 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. editor responsibility 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) ... I agree. Ok, I am closing this one and Milo please close 121357. Thanks. |