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

> 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.


> /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]

Reply via email to