Hi Thomas, a couple of comments on your comments:
1.) dispose() i try to get a meaningful benchmark which shows that performance of batik 1.7 is better than 1.6. - that's what i'd expect. However, that is difficult to prove. I run the imagetranscoder on a couple of svg-files using jdk1.4, 1.5 and 1.6 on the old set of batik1.6 jars against a current jar. the current jar is *always* slower! :-( watching the profiler results it seems, that the current code creates more work for the garbage collector. Not more garbage in bytes, but in quality - it seems to be more 'sticky'. The old batik spends (lets say) 15% of its time in gc, the current batik spends 22% of its runtime in gc (working on the same input). A likely cause of this are caches, finalizers, references etc. so, the manually clearing obsolete datastructures is an (so far not successful) attempt to simplify the work of gc. There are not many dispose() methods to try.. Of course, when i run out of ideas i can cheat with a simple benchmark: load + render one image to screen, then stop the watch, ignoring gc-cost... Any ideas of fundamental changes in object structure since 1.6? 2.) arraycopy. after the vm-sourcecode was made public last year i spend some time poking around to see what is really behind the various myths about the hotspot capabilities. the object of the investigation was the float-to-int conversion. There is an x86 instruction for that, but it does a rounding conversion. to have to truncation, the fpu must be set to another rounding mode. that costs 40 cycles. after conversion, the mode must be restored (costs another 40 cycles). Newer cpu-models have mmx, sse, ss2e instructions. Among those is a optimized float-to-int conversion, bypassing the fpu. So, the hotspot detects the current cpu-model and generates the best float-to-int conversion available. Hotspot has a number of tricks to compile arraycopy(). It knows, that it deals with a primitive array. It knows, that it doesnt need to check source and destination index (0 is always valid). Both are 0, so no need for overlap check. The copy-size is fixed and small, so it doesnt produce a block-move, just some load/store-instructions. This Hotspot-thing is a really smart piece of code. However, I wouldnt bet on the capabilities of a jdk1.3 client... The point is to use idioms: when it is a block-move, it should be written as a block move. Probably, the best way to write this is to use the switch-statement to select the number of slots to copy, and then have only one arraycopy after the switch. Unfortunately, so far i have not found a way to make it use the fancy sse-instructions to pack/unpack the bytes <-> int. That would give a real boost to any pixel-packing graphics app. 3.) whitespace is removed automatically when i open a file. ok, i can refrain from committing 'white-space-only' changes. greetings dieter ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[email protected]> Cc: <[email protected]> Sent: Thursday, February 08, 2007 11:52 AM Subject: Re: svn commit: r504819 - in /xmlgraphics/batik/trunk/sources/org/apache/batik: bridge/ ext/awt/geom/ gvt/renderer/ util/ > Hi Deiter, > > A couple of comments on this > > [EMAIL PROTECTED] wrote on 02/08/2007 03:23:21 AM: > > > xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/BridgeContext. > > The main purpose of 'dispose' is to remove references to objects > that otherwise would not have references removed. In the case of > the Maps the whole map is about to become unreferenced meaning that > any references it has will become meaningless. Unless you know > something I don't I suspect that calling 'clear' on these just > adds work and doesn't help anything.... > > > java Thu Feb 8 00:23:19 2007 > > @@ -1450,6 +1450,15 @@ > > if (focusManager != null) { > > focusManager.dispose(); > > } > > + if ( elementDataMap != null ){ > > + elementDataMap.clear(); > > + } > > + if ( nodeElementMap != null ){ > > + nodeElementMap.clear(); > > + } > > + if ( elementNodeMap != null ){ > > + elementNodeMap.clear(); > > + } > > } > > I understand that System.arraycopy is by far > the fastest way to copy large amounts of data, I've > always assumed that for small chunks of data the > overhead needed for arraycopy to get going (function > call, data type matching, array pinning(?) etc) way > outweighed the speed advantage once it is going. > > I don't know if there is 'magic' under the > hood that avoids this (for example some C compilers > will replace calls to memcpy). So I'm wondering > if you know something I don't or if you are just > operating on the conventional wisdom of use > arraycopy. > > > - coords[0] = (float)values[valsIdx]; > > - coords[1] = (float)values[valsIdx+1]; > > - coords[2] = (float)values[valsIdx+2]; > > - coords[3] = (float)values[valsIdx+3]; > > + // coords[0] = values[valsIdx]; > > + // coords[1] = values[valsIdx+1]; > > + // coords[2] = values[valsIdx+2]; > > + // coords[3] = values[valsIdx+3]; > > + System.arraycopy( values, 0, coords, 0, 4 ); > > break; > > PS. The space thing. I don't mind the removal of > trailing whitespace, but can we do this in one large > pass rather one file at a time? It makes your > commits very hard to read. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
