Re: A performance patch for PDFInfo class

[Henrik Olsson]

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

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