Hi William,
>>>>> "WH" == William Huang <[EMAIL PROTECTED]> writes:
WH> I am running some examples smaller than 30KB. Here I attached
WH> a sample file which is 24KB.
Ok, I would consider these small files.
WH> My computer has a Pentium2 352MHz CPU and 224MB RAM.
Ok, I would consider this a 'slow' computer. :)
WH> I have made a standalone application and an applet using my
WH> bundled kit including Batik, Crimson parser and Rhino Ecmascript
WH> engine. The standalone application uses a JFileChooser to choose
WH> svg files for display. The Applet is also tested locally using
WH> IE6.0 and locally installed Microsoft IIS. The standalone
WH> application took around 10 seconds to build and 2 seconds to
WH> render.
What happens if you reload the image a few times with the app?
(just open the same file several times).
WH> The Applet took around 30 seconds to build and 45 seconds to
WH> render. It seems that the applet is much slower than the
WH> standalone application.
Similarly what happens if you reload the image?
On my system with squiggle[*] the first render is ~1sec,
subsequent renders are ~.25 sec (the largest single chunk being the
loading of the XML).
[*] One of the things squiggle does to improve 'perceived' performance
is preload many of the Batik classes. This is what is happening
during the progress bar when Squiggle starts.
WH> Could you give me some suggestions about how to optimize our
WH> application? I am considering keeping images as linked image files
WH> instead of rendering them as complex path elements.
Well, referencing them as images may be the right choice - all
depends on why you wanted SVG on the client.... You might also
consider doing on the fly conversion of the SVG in a servlet, or
automated 'offline' generation using something like the svgrasterizer
in Batik.
WH> Since there are performance difference between the standalone
WH> application and the Applet, is it possible to optimize the Applet?
WH> That is, allocating more resources to the Applet such as memory or
WH> even CPU? Does the security check for Applet environment cause
WH> significant performance degradation?
I suspect the class verifier is a good part of the reason that the
applet is so much slower. If you can 'install' the Batik jar files in
the jre's ext directory I think that it skips class verification.
However, what you really need to do is keep the applet around for a
while so it doesn't have to load it's self from scratch as I believe
performance will improve significantly after the first image or two.
WH> Thanks a lot.
WH> With best regards, William
WH> -----Original Message----- From: Thomas E Deweese
WH> [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003
WH> 10:18 AM To: Batik Users Subject: RE: Question about Batik
WH> performance
>>>>> "WH" == William Huang <[EMAIL PROTECTED]> writes:
WH> I made an application which bundle Batik, Rhino Engine and SAX2
WH> parser together for SVG processing. I found there is noticeable
WH> delay from class loading to rendering completion.
WH> So Java is notoriously hard to get 'good' performance figures
WH> from. The first things that comes to mind is class loading
WH> issues, the first rendering from Batik takes for ever because all
WH> the classes need to be loaded - there is almost no way for us to
WH> avoid this.
WH> The problem is extremely significant when the path is a little
WH> complex which costs tens of seconds to get done.
WH> Just so I have a decent frame of reference what do you mean by
WH> 'a little complex'? 1K, 10K, 100K 1Mb 10Mb?
WH> What features are you using, filters, patterns, gradients,
WH> use, text, etc. Are you using them heavily/lightly...
WH> Is there some ways to improve the performance or has Batik project
WH> group have a plan in this area? For example, improving file I/O
WH> and TCP networking I/O speed using the Java 1.4 NIO,
WH> I don't think we are likely to ever write our own XML parser,
WH> so unless crimson/Xalan/whatever does this, we won't.
WH> parsing element more efficiently,
WH> Well we have done a bunch of this already (note we have our
WH> own float parser etc). If you can provide good clear benchmarking
WH> data that points to areas that need optimization we will take a
WH> look. However, the last time I looked XML parsing was getting to
WH> be a small enough part of the pie to not worry about.
WH> I spent a lot of time on trying to optimize text but never got
WH> speed to a point where I was really happy with it, in the end the
WH> biggest drains were JDK text classes, so unless I rewrote them I
WH> wasn't going to do any better.
WH> better integration with other open-source projects, and so on?
WH> What other open-source projects?
WH> This is an open-source project so we are open to just about
WH> anything (if we weren't people could just take the code and do
WH> what they want). But especially right now committer resources are
WH> limited so don't expect us to do large scale rewrites (if other
WH> want to contribute, please do!).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
