Hi all.

I have measured the number of AbstractStringBuilder method invocations when
executing NetBeans 6 (and making some work for 5 minutes) and when executing
for a while a Glassfish V2 with a typical web application
(Struts+Spring+Hibernate). These are the interesting and empirical results:

GLASSFISH
=========
num new AbstractStringBuilder:   1094600
num StringBuilder.toString() :    648524
num StringBuffer.toString()  :    436706
num expandCapacity()         :    993383
num appendChar()             :  13604867
num appendStringsOrObject()  :   2062881
num appendCharArray()        :     26999
num appendCharSequence()     :      1435
num appendInt()              :     42208
num appendLong()             :      9744
num appendBoolean()          :      2339
num appendFloat()            :         0
num appendDouble()           :         3
num appendStringBuffer()     :         8
num appendCodePoint()        :         0
num trimToSize()             :         0
num length()                 :    273672
num setLength()              :     33242
num getsOrCountsOrIndexOf()  :    151377
num replace()                :     10778
num delete()                 :       163
num inserts                  :      1159
num substring()              :       154
num reverse()                :         0

NETBEANS
========
num new AbstractStringBuilder:   2996681
num StringBuilder.toString() :   1670769
num StringBuffer.toString()  :   1285300
num expandCapacity()         :   1737419
num appendChar()             : 119975412
num appendStringsOrObject()  :   3323190
num appendCharArray()        :    108522
num appendCharSequence()     :     96564
num appendInt()              :     10834
num appendLong()             :      1694
num appendBoolean()          :       470
num appendFloat()            :       360
num appendDouble()           :         0
num appendStringBuffer()     :         0
num appendCodePoint()        :         0
num trimToSize()             :         0
num length()                 :    142646
num setLength()              :     21448
num getsOrCountsOrIndexOf()  :    109426
num replace()                :      4432
num delete()                 :      5753
num inserts                  :         0
num substring()              :      1241
num reverse()                :         3


My conclusions:

        - The number of append(char) is bigger than append(String) and much
bigger than other inserts (mainly in the Netbeans execution), so my
StringAppender approach wouldn't perform good as predicted by Rémi and
others. The number of append(int), append(float), append(Boolean) is very
low.
        - In a very few situations a Builder/Buffer is reutilized after
calling toString()
        - expandCapacity() is invoked a lot of times!!!
        - Other operations (different than appends) are invoked a very few
times.

So I suppose that my two proposals have few sense in general (haven't
they?), but maybe these figures can help to reconsider the value of the
default buffer length or can help others trying to make String/StringBuilder
faster. Heap allocation and System.arraycopy calls must be reduced anyway!

P.S: Nevertheless I attach the "final" version of my modification to
String.java and of StringAppender, which has some optimizations to
append(char) but not sufficient... I think.

Best regards,
Jesús

-----Mensaje original-----
De: Ulf Zibis [mailto:[EMAIL PROTECTED] 
Enviado el: lunes, 22 de septiembre de 2008 16:51
Para: Server Performance
CC: core-libs-dev@openjdk.java.net
Asunto: Re: API change proposal: String concatenation boost

Hi Jesús

this is a very interesting proposal.

Some days ago I had a similar case. I had to instantiate a String from 
some single char's:
   int count;
   String s = new String (new char[] {'I','d', ' ', (char)count});
My proposal is to modify constructor String(char[] chars) to 
String(char... chars), so we can code:
  String s = new String ('I','d', ' ', (char)count);

... just my 2 cent.

-Ulf


Attachment: String.java.diff
Description: Binary data

Attachment: StringAppender.java
Description: Binary data

Reply via email to