Bug 125006

Summary:	ClassFile wastes memory
Product:	[Eclipse Project] JDT	Reporter:	Chris Laffra <laffrac>
Component:	Core	Assignee:	Jerome Lanneluc <jerome_lanneluc>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	fraenkel
Version:	3.2	Keywords:	performance
Target Milestone:	3.2 M5
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Chris Laffra

2006-01-24 10:15:56 EST

The constructor for org.eclipse.jdt.internal.core.ClassFile has an interesting space optimization:

   // don't hold on the .class file extension to save memory
   // also make sure to copy the string (so that it doesn't hold on the 
   // underlying char[] that might be much bigger than necessary)
   this.name = new String(name.substring(0, name.length() - 6));

An interesting idea, but on the VM I checked, this does not save any memory at all. The original character array is held onto along the calls to substring and the copy constructor.

As a result, we are doing extra work and do not save any memory.

Comment 1 Philipe Mulet

2006-01-24 11:05:26 EST

I remember jerome fixing a couple of these already.

Comment 2 Jerome Lanneluc

2006-01-24 11:22:21 EST

I wanted to avoid:
  StringBuffer buffer = new StringBuffer(ame.substring(0, name.length() - 6));
  this.name = buffer.toString();
which is even more costly.

Would it be possible for the VM you're using to change its behavior and do the copy of the char array if its length is greater than the String's size ?

Comment 3 Michael Fraenkel

2006-01-26 15:57:25 EST

The StringBuffer example actually wastes even more space.  The only guaranteed way to reduce space is to use getChars().  This will of course cause 2 copies but you will always have the smallest amount of space used.

Comment 4 Jerome Lanneluc

2006-02-08 07:31:12 EST

Note this code has moved to PackageFragment#getClassFile(String).
Changed PackageFragment#getClassFile(String) to use getChars(...).

Comment 5 Frederic Fusier

2006-02-14 11:40:50 EST

Code verified for 3.2 M5 using build I20060214-0010.