StringBuffer.build() - a way to create strings without unnecessary allocations

[Rémi Forax]

I will answer with a question.
Correct me if i'm wrong.
You see no slowdown to use StringBuffers instead of StringBuilders.
This means that perhaps the VM is able to remove synchronization block.
Which means that the NetBeans startup is most done by one thread.
If you want to improve the startup time, why not doing this initialization
in parallel.

Rémi

On 12/09/2010 12:03 AM, Jaroslav Tulach wrote:
> Hello.
> Can anybody hear me? I'd like to talk to someone who cares about String,
> StringBuffer and StringBuilder. I am NetBeans Platform architect and I'd like
> to use this opportunity to fasten start of NetBeans as well as improve OpenJDK
> project. Here is my story:
>
> I've been investigating the memory allocations during NetBeans start. I've
> noticed that we are allocating about 60MB of char[] mostly due to parsing of
> various configuration files. Suprisingly at least half of these 60MB is
> garbage collected quickly. This is because we use StringBuffer/Builder to
> concatenate the texts and then convert them to String. The conversion to
> String however allocates new array. I believe this is less then optimal.
> However there is no way I can tell the Java libraries to be more effective.
>
> That is why I decided to create my patch. It adds StringBuffer.build() method
> which can create Strings without unnecessary copying. It adds
> StringBuilder.build() method too, for symetry, but that one is not that
> effective (I don't know how to make it robust without usage of
> synchronization). If I had StringBuffer.build, I could allocate only 30MB of
> data on NetBeans startup and very likely make it faster. Can you consider
> adding this method to JDK7?
>
> I am attaching my patch that adds the new API. I can refine it, add new tests,
> etc. I just need a buddy interested in StringBuffer to guide me. I belive that
> together we can make NetBeans start faster and OpenJDK7 better. Can you help
> me?
>
> -jt