Community
Participate
Working Groups
Bug 90179 raises a memory issue which is due to the large number of StyleRange objects created by Eclipse editors. Is there a way we can reduce the number? To bring up a runtime workspace, the number of these objects which is created is quite large, and many seem to be created here: org.eclipse.swt.custom.StyleRange.clone(StyleRange.java:151) org.eclipse.jface.text.TextViewer.modelStyleRange2WidgetStyleRange(TextViewer.java:4979) org.eclipse.jface.text.TextViewer.addPresentation(TextViewer.java:4225) Is there maybe a way we can reduce the number of temporary StyleRange objects created?
We will have to investigate.
I noticed that in DefaultDamagerRepairer#addRange(), it is creating a lot of StyleRange objects that seem to have all of the fields set to their default values: null foreground and background, SWT.NORMAL, and no underline or strikethrough. Maybe this is an area where the number of objects can be reduced?
(In reply to comment #2) > I noticed that in DefaultDamagerRepairer#addRange(), it is creating a lot of > StyleRange objects that seem to have all of the fields set to their default > values: null foreground and background, SWT.NORMAL, and no underline or > strikethrough. Maybe this is an area where the number of objects can be reduced? Trying this out....
Possibily Billy, remember that emtpy StyleRange can be used to reset the default colors and font to a range.
Tom, please comment the current state of your findings and what we improved for the Java editor for 3.1.
There are many temporary objects being created during painting. Not sure *how* bad this really is on current VMs - of course they create garbage, but I thought that young objects died fast... A) o.e.jface.text.Region Everywhere we work text ranges, they are usually represented as an IRegion, typically implemented by a Region. Evertime something in the document model has to be mapped to widget coordinates, a new Region is created: - modelRange2WidgetRange, widgetRange2ModelRange and similar B) StyleRange Basically the same as A), but with StyleRanges - this is mainly used by the presentation framework that handles syntax highlighting, and by the semantic highlighter. Since the coordinate conversion is still IRegion based, we actually create two Region instances and one additional StyleRange for every StyleRange we want to convert. For 3.1, we changed JavaSourceViewer.modelStyleRange2WidgetStyleRange to not clone StyleRanges any longer, but simply modify the range that was passed in. We cannot do this for TextViewer as we cannot modify the implicit contract of a framework method. However, we could change addTextPresentation to use a different conversion method that is speced to modify the StyleRanges. Note that callers of addTextPresentation cannot expect the presentation to remain unchanged even today, as ITextPresentationListeners are allowed to change the presentation before it is applied to the widget. Also, DefaultDamagerRepairer creates many style ranges as said in comment 2. However, not creating style ranges for ranges that have the default style proved not easy, as the extent of the created ranges is used to determine the area that has to be changed on the widget.
moving back to inbox.
*** Bug 96462 has been marked as a duplicate of this bug. ***
See also bug 119384.
*** This bug has been marked as a duplicate of bug 2537 ***
