"Kevin O'Neill" <kevin@rocketred. To: FOP Developers <[EMAIL PROTECTED]> 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]