Community
Participate
Working Groups
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.
Good find. Olivier, pls investigate. I hope performance isn't an issue here.
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.
Fixed and released in HEAD.
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.
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.
