Hi Jonathan,
"Johnson, Jonathan" <[EMAIL PROTECTED]> wrote on 03/08/2006 03:49:34 PM:
> Does anyone know how I fix the following performance problem?
There isn't one... ;)
> I have found that creating a svg document from a svg file can be very
> slow. I'm using Java 1.5 on a decent, fast machine. I have the
> following svg document.
I'm guessing you are fairly new to Java?
> When I drop it into Firefox it appears instantly.
Really? how long does it take firefox to start and show the document
from a 'cold' start? When FireFox isn't already running? It takes
20sec on my laptop (and it was just up). It's important to try and
make real 'apples' to 'apples' comparisons.
> When I use the following Batik API calls it takes about seven seconds
> to load. Other svg files can take ~200 millisecond to load.
The 'problem' such as it is, is that Java apps aren't really
precompiled binaries. There is a comparatively large amount of
overhead in starting a JVM and reading all the basic support classes
(runtime linking etc). Also all modern JVM's use Just in Time compilers
which will compile critical code to machine code 'on the fly'. So
simple tests like 'how long does it take to transcode one SVG file'
are _very_ poor indicators of performance. So to take your example I
added the following main:
static public void main(String args[]) {
try {
File f = new File(args[0]);
for (int i=0; i<10; i++)
new SvgImage(f.toURL());
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
This just reads the same file 10 times in a row. The output is
below. This is after the JVM is 'warm' since I've run it a bunch of
times (files in cache etc), which is why the first one only takes
400ms as opposed to up to several seconds. As you can see the follow
on 'loads' are very quick because all the needed code is loaded and
the important bits have been JITed.
Using xml reader: org.apache.xerces.parsers.SAXParser
Time to create SAXSVGDocumentFactory: 0
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 410
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 10
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 20
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 0
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 0
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 10
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 10
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 10
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 0
Time to create:
file:/C:/Apps/cygwin/home/l449433/dev/batik/svg12-batik/foo.svg: 10
> I suspect the above path stoke may be the bottleneck, but that's not a
strong
> argument since it loads so quickly in the Firefox svg renderer.
No you haven't even rendered anything yet...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
