Bug 120410

Summary: Wasted space on problems due to large underlying char[]
Product: [Eclipse Project] JDT Reporter: John Arthorne <john.arthorne>
Component: CoreAssignee: Olivier Thomann <Olivier_Thomann>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 3.2   
Target Milestone: 3.2 M5   
Hardware: PC   
OS: Windows 2000   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=532088
Whiteboard:

Description John Arthorne CLA 2005-12-12 12:34:27 EST
Build: I20051206

I was doing some debugging with markers, and happened to notice that on Java problem markers, the "message" attribute is often backed by a char[] that is much larger than the message.  In one random source file, there was a problem message with 49 characters backed by a char[] of size 109, and another with 34 characters in a char[] of size 56.  This extra overhead would quickly add up in a workspace with 6000 markers (not unusual for a large workspace with many warnings).

I noticed this line in DefaultProblemFactory that may be partly responsible:

if (output == null) output = new StringBuffer(length+problemArguments.length*20);

A problem marker with several short arguments will add lots of extra padding to the char[] using this algorithm.  Calling new String(buffer.toString()) should be enough to ensure the char[] is of optimal size, but of course that adds some time cost. If speed is a concern, it could do a first pass to determine the exact message size, and then create a char[] or StringBuffer of correct size.
Comment 1 Philipe Mulet CLA 2005-12-12 15:26:23 EST
Good find. Olivier, pls investigate.
I hope performance isn't an issue here.
Comment 2 Olivier Thomann CLA 2005-12-13 21:24:44 EST
I will call new String(output.toString()) for now. I will monitor the performance test results to see if this has an impact.
Since this happens only when we report errors I doubt that this would have a bug performance impact.
Comment 3 Olivier Thomann CLA 2005-12-16 23:00:23 EST
Fixed and released in HEAD.
Comment 4 Philipe Mulet CLA 2005-12-17 08:30:32 EST
Well, we create more problems than we report in the end (based on actual severity). So in presence of optional diagnostics, it could be an issue.
Comment 5 Maxime Daniel CLA 2006-02-15 09:51:47 EST
Verified for 3.2 M5 using build I20060215-0010.
The new code will save space, as requested by this bug.
Olivier/Philippe pls open separate bug if you want to track possible time penalty further.