Hi Kevin.
Im sorry I got in to the dicussion att the wrong time...
> 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.
You are totaly right, in just adding strings together like:
public String testStringBufferChained() {
return (new StringBuffer().append("this ")
.append(makeString("is "))
.append("a ")
.append(makeString("test"))).toString();
}
And there are nothing to gain.
But there are to many places where strings are added over and over to each other, and that was what I was talking about.
Butt never mind I have to read the mails better next time.
/Henrik
| "Kevin O'Neill" <[EMAIL PROTECTED]>
2002-11-12 20:26
|
To: FOP Developers <[EMAIL PROTECTED]> cc: Subject: Re: A performance patch for PDFInfo class |
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.
> 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]
