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.
Both NbJavaFoldManager$ImportsFoldInfo and NbJavaFoldManager$InitialFoldInfo keep start and end position in document that is also held by the fold. Similarly for javadoc folds hasmap init2folds uses String version of MOFID as a key. This is expensive as the string is 53 chars long and keeps 112+24 bytes. The value again references mofid from ClassMemberFoldInfo.id and through ClassMemberFoldInfo.classMember.mofId too. Using MOFID object as a key would be enough but requires it was a part of API.
Regarding the first problem this is IMHO irrelevant for the two mentioned classes as they are only held during the pending UpdateFoldsRequest then they should be released and only the fold itself should remain until there is a need to create another request. To clarify the process: the updating of the folds is done in two phases: 1) collect all the information necessary for folds creation or changing; this has to run outside of the AWT thread - in a dedicated RequestProcessor 2) update the folds in the copmonent's fold hierarchy; this has to run in AWT; it uses the information stored in the UpdateFoldsRequest created in the phase 1) What could be eliminated are the NbJavaFoldManager$ClassMemberFoldInfo.classMemberStartPos and others but only once the phase 2) finishes. I'll try to look at that whether it would not break anything. Regarding 2) this is IMHO not an editor's issue. We only need to keep some identity of the folds and use it in maps too but we don't really care whether it's String or anything else.
Do we still have this problem? We don't use MOFIDs anymore AFAIK. Can we remeasure it again? Thanks
We still hold the positions. I do not think we hold any equivalent of MOFID.
later.
NetBeans.org Migration: changing resolution from LATER to WONTFIX