"Kevin O'Neill"
<kevin@rocketred. To: FOP Developers
<[EMAIL PROTECTED]>
com.au> cc: (bcc: Thomas
Seremet/GCR-NAmerica/GRN)
Subject: Re: A performance patch for
PDFInfo class
11/12/2002 02:26
PM
Please respond to
fop-dev
On Wed, 2002-11-13 at 02:25, Henrik Olsson wrote:
> >StringBuffer xxx.append("foo").append("bar");
> >
> >understanding what the compiler does is the secret to optimizing
> >Strings.
>
> Hi Kevin.
> Its not an issue of what code is fastest here, its about creation and
> destuction of objects.
There is NO difference in the garbage created by String a = "foo" +
"bar"; and StringBuffer xxx.append("foo").append("bar"); They compile to
the same thing. Have a look at the pcode.
Some more insight or confusion. The byte code maybe similar in the sense
that String uses "".concat() and
StringBuffer uses new StringBuffer().append to do their individual
concatenations but the way they are
treated by the JVM is not the same. Of course not all JVM's are created
equal but Strings are stored as constants thus you see the ldc opcode when
creating Strings. Even though a String holds on to an internal
character array as does a StringBuffer, a String creates a new String when
it is concatentating another String to itself NOT modifing its internal
character array. On the other hand a StringBuffer actually modifies its
internal character array to represent the new String though this is
accomplished by increasing the array size by creating a new char array.
This is only part of the story since there is a difference between Strings
stored in the so-called constants pool and new Strings created during
runtime which do not go into the constants-pool automatically. Very good
info concerning this on the web.
My point is that that the amount of "garbage"=unreferenced Objects in my
view would be substantially more from Strings way of concatentation then
StringBuffers if the StringBuffer is well managed in terms of capacity and
usage.
A quick skim with a decompiler/editor and some tests will show this. I'm
sure most everyone here understands Java Strings and StringBuffers, so I am
sorry for the spiel in advance.
Tom
> I have done several measurements on the fop to find the bottlenecks and
> one of them are strings objects.
> I think we agree on that gc is slow and one way to avoid gc its to use
> StringBuffers instead of Strings while we are putting them together.
> I have runned some profileing on the fop-0.20.4 and my tuned one (patch
> 14013) with the same fo-files.
> And there are 680010 Strings in created in the fop-0.20.4 compared to
> 170395 Strings created in the tuned one, and this gives us a hint that
the
> gc dont have to run that offen and we can do some real work instead,
speed
> increased with 20-30%.
There is alot of += these should be removed as part of the move towards
1.0
> Im also working on another preformence problems with properties and
makers
> but it takes a step from the fo-spec and needs to know some things about
> the layout (pre parse the xsl before adding the xml data to it).
> And it will increase the speed the bigger a layout gets...
> And it can compete with commercial pruducts as StreamServe.
>
> Se xsl chart at http://nohardcore.tripod.com/fop/FOP-test.zip
>
> If You are interested in the code just say so.
Always.
> /Henrik
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
