xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Huang" <shu...@xperient.net>
Subject RE: Question about Batik performance
Date Mon, 06 Jan 2003 18:33:53 GMT
Dear Thomas,

I am running some examples smaller than 30KB. Here I attached a sample
file which is 24KB. My computer has a Pentium2 352MHz CPU and 224MB RAM.
I have made a standalone application and an applet using my bundled kit
including Batik, Crimson parser and Rhino Ecmascript engine. The
standalone application uses a JFileChooser to choose svg files for
display. The Applet is also tested locally using IE6.0 and locally
installed Microsoft IIS. The standalone application took around 10
seconds to build and 2 seconds to render. The Applet took around 30
seconds to build and 45 seconds to render. It seems that the applet is
much slower than the standalone application.

Could you give me some suggestions about how to optimize our
application? I am considering keeping images as linked image files
instead of rendering them as complex path elements. Since there are
performance difference between the standalone application and the
Applet, is it possible to optimize the Applet? That is, allocating more
resources to the Applet such as memory or even CPU? Does the security
check for Applet environment cause significant performance degradation?

Thanks a lot.

With best regards,
William 

-----Original Message-----
From: Thomas E Deweese [mailto:thomas.deweese@kodak.com] 
Sent: Monday, January 06, 2003 10:18 AM
To: Batik Users
Subject: RE: Question about Batik performance

>>>>> "WH" == William Huang <shuang@xperient.net> 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. 

    So Java is notoriously hard to get 'good' performance figures
from.  The first things that comes to mind is class loading issues,
the first rendering from Batik takes for ever because all the classes
need to be loaded - there is almost no way for us to avoid this.


WH> The problem is extremely significant when the path is a little
WH> complex which costs tens of seconds to get done.

    Just so I have a decent frame of reference what do you mean by 'a
little complex'?  1K, 10K, 100K 1Mb 10Mb?

    What features are you using, filters, patterns, gradients, 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, 

    I don't think we are likely to ever write our own XML parser, so
unless crimson/Xalan/whatever does this, we won't.

WH> parsing element more efficiently, 

    Well we have done a bunch of this already (note we have our own
float parser etc).  If you can provide good clear benchmarking data
that points to areas that need optimization we will take a look.
However, the last time I looked XML parsing was getting to be a small
enough part of the pie to not worry about.

    I spent a lot of time on trying to optimize text but never got
speed to a point where I was really happy with it, in the end the
biggest drains were JDK text classes, so unless I rewrote them I
wasn't going to do any better.

WH> better integration with other open-source projects, and so on?
 
    What other open-source projects?

    This is an open-source project so we are open to just about
anything (if we weren't people could just take the code and do what
they want).  But especially right now committer resources are limited
so don't expect us to do large scale rewrites (if other want to
contribute, please do!).

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message