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]