Re: A performance patch for PDFInfo class
"Kevin O'Neill"
com.au> cc: (bcc: Thomas
Seremet/GCR-NAmerica/GRN)
Subject: Re: A performance patch for
PDFInfo class
11/13/2002 05:41
AM
Please respond to
fop-dev
>
>
>> 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.
>
>Okay firstly, please look at the pcode generated earlier in this thread.
>It was generated by the moder compiler on jdk 1.4.0 the string addition
>is indeed concatinated using StringBuffer.append()
>
>public String testStringBufferChained()
>{
>return (new StringBuffer().append("this ")
>.append(makeString("is "))
>.append("a ")
>.append(makeString("test"))).toString();
>}
>
>public String testStringAdd()
>{
>return
>"this "
>+ makeString("is ")
>+ "a "
>+ makeString("test");
>}
>
>becomes ...
>
>Method java.lang.String testStringBufferChained()
> 0 new #2
> 3 dup
> 4 invokespecial #3
> 7 ldc #4
> 9 invokevirtual #5 append(java.lang.String)>
> 12 aload_0
> 13 ldc #6
> 15 invokespecial #7 makeString(java.lang.String)>
> 18 invokevirtual #5 append(java.lang.String)>
> 21 ldc #8
> 23 invokevirtual #5 append(java.lang.String)>
> 26 aload_0
> 27 ldc #9
> 29 invokespecial #7 makeString(java.lang.String)>
> 32 invokevirtual #5 append(java.lang.String)>
> 35 invokevirtual #10
> 38 areturn
>
>Method java.lang.String testStringAdd()
> 0 new #2
> 3 dup
> 4 invokespecial #3
> 7 ldc #4
> 9 invokevirtual #5 append(java.lang.String)>
> 12 aload_0
> 13 ldc #6
> 15 invokespecial #7 makeString(java.lang.String)>
> 18 invokevirtual #5 append(java.lang.String)>
> 21 ldc #8
> 23 invokevirtual #5 append(java.lang.String)>
> 26 aload_0
> 27 ldc #9
> 29 invokespecial #7 makeString(java.lang.String)>
> 32 invokevirtual #5 append(java.lang.String)>
> 35 invokevirtual #10
> 38 areturn
>
>
>So once again I say these are these are identical, the underlying VM has
>no idea of any difference. I would though contend that the String
>addition is easier to read.
I know I also came in late into this thread. I would like to say I am very
excited about the possibilities of FOP in the future and the already
realized gains FOP gives. My overall grasp of FOP at this moment is still
limited but I have been delving into the code and using it for a current
project for the past 2 months. In no way am I trying to be insulting to
anyone. I realize everyone here is very well versed in various areas of
programming. Performance has always been an interest to me in general so I
enjoy these types of topics. I don't mind being proven wrong.
Yes. You are correct on your assumptions based on your cod
Re: A performance patch for PDFInfo class
"Kevin O'Neill"
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]
