Re: [Fwd: Re: Batik performance questions]

[Marc Chung <mc...@fastq.com>]

> Hi Marc,

Hi Thomas,

Thanks for taking the time to answer my questions.  Replies are inlined.

> 
> Marc Chung wrote:
> 
> > Performance questions
> 
> > I'm using Batik to generate charts and graphs dynamically within a servlet
> > container. (Various data graphs, SVG size: ~4-5kb)
> > 
> > Currently I do this by creating an SVG, and then modifying the elements
> and
> > attributes to describe my graph.  Then, depending on the type of report
> > requested (HTML or PDF), I either transcode the SVG into a PNG or I use
> the
> > PrintTranscoder.print(Graphics, PageFormat, int) to embed the image into my
> PDF
> > (Using the iText PDF libraries).
> 
>    Do you use the Batik DOM to do this manipulation of the Document?
> If you don't then the whole document is "copied" into a Batik DOM
> Implementation (so we have CSS and other things required by SVG).
> This isn't usually a huge time suck but it is generally an unneeded
> one.
> 

I'm not using the Batik DOM to manipulate my XML.  I'm using NanoXML to do my
XML manipulation.  The result (SVG) is returned in a String which is then
wrapped in a StringReader and fed to the TranscoderInput.  I had a feeling that
the document needed to be re-"copied" into a DOM.  So I ran the some tests
(through a profiler).

In both file formats, after the print() or transcode() method is called, the
tree appears to be traversed (Lots of calls to
o.a.b.gvt.AbstractGraphicsNode.getTransformedBounds,
getTransformedPrimitiveBounds)).  Eventually, a considerable chunk of time is
spent in the constructor of o.a.b.gvt.text.BidiAttributedCharacterIterator.  

There are quite a few interesting comments, as well as flow control statements
in the constructor of that particular class that I was hoping Bella (@author) or
Vincent (cvs checkin) could elaborate upon.  For instance, what would I do, if I
didn't want to check for bidi text?

> > I enjoy the power of the library, but my only real problem is that it's
> slow. 
> > (1 second per image, 14 images / page.  The PrintTranscoder takes
> noticeably
> > longer.)
> 
>    What platform (OS/CPU roughly) are you running on?
> 

My development box is a Pentium 4 2.6GHz machine with 512mb of RAM.  I am
running Windows XP.

> > Is this speed normal?  
> 
>    1 second per image seems slow to me.  Can you post sample content?
> Is the 1sec for PNG output or PDF?  How large a PNG (pixels) are we
> talking abount?
> 

I can't post sample content, but I may be able to send you an SVG and/or a PNG
of my results, if you would like.  The images tend to be about 200 x 300 pixels,
 4-6 per page (served up through a servlet)

> > Are there ways to enhance the speed?  
> 
>    As you might guess there is no magic -go-really-fast switch.
> One is that PNG output is much slower than JPEG - I know that
> JPEG is not ideal for graphs but it may be something to consider.

It's not so much the PNG output that I'm worried about, we can cache the images
on the server effectively providing the user with a fast web experience.  The
real bottleneck arises when a request has been made for a report in PDF.  The
process attempts to transcode/print a large number of images (20) and takes
about a second for each image.  In both cases (PNG and PDF), as I happened to
notice earlier, the BidiAttrCharIter class appears to take up a good chunk of
time.  I'm not sure if I'm on the right track, but I would prefer to spend some
time in that class either tweaking the Bidi code, or turning it off completely.

> > I would really like to increase performance.  
> > Is this an appropriate use of the PrintTranscoder class?  
> 
>    Well it seems a little hokey to me, I would write a new
> transcoder subclass for the iText library.  If you look at
> the existing transcoder examples it should give you a good
> idea of how to do it.
> 

That's what struck me at first.  Would writing such a transcoder require
intimate knowledge of the SVG and PDF spec?  Would I need to know the details of
how the GVT works too?

> > Is there another way of writing an SVG to a Graphics object?  
> 
>    Sure, all the image transcoders also "write an SVG to a Graphics
> object".  You might also want to look at the pdf-transcoder that is
> built into Batik (using code from FOP).
> 

I've thought about using FOP, but the developers have listed implementation
issues (http://xml.apache.org/fop/graphics.html) which have discouraged me from
using it.  But I will keep this in mind.

> > Should I be cautious about the usage of the PrintTranscoder in a
> multithreaded
> > environment?
> 
>    You should be alright as long as you don't try and use the same
> document/Graphics across threads.  But I don't know anything about
> the iText library so perhaps it has problems internally.
> 

Good to know.  But just to qualify:  say I were to launch 10
PrintTranscoders/PNGTranscoders in 10 separate threads, there should not be any
thread-related issues (no blocking or waiting on some shared resource), right?

Thanks for your suggestions.

-Marc

-------------------------------------------------
FastQ Communications 
Providing Innovative Internet Solutions Since 1993


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

Re: [Fwd: Re: Batik performance questions]

[Thomas DeWeese <Th...@Kodak.com>]

Hi Marc,

>>Marc Chung wrote:
>>
>>
>>>Performance questions

>>   Do you use the Batik DOM to do this manipulation of the Document?
>>If you don't then the whole document is "copied" into a Batik DOM
>>Implementation (so we have CSS and other things required by SVG).
> 
> I'm not using the Batik DOM to manipulate my XML.  I'm using NanoXML to do my
> XML manipulation.  The result (SVG) is returned in a String which is then
> wrapped in a StringReader and fed to the TranscoderInput.  I had a feeling that
> the document needed to be re-"copied" into a DOM.  So I ran the some tests
> (through a profiler).
> 
> In both file formats, after the print() or transcode() method is called, the
> tree appears to be traversed (Lots of calls to
> o.a.b.gvt.AbstractGraphicsNode.getTransformedBounds,
> getTransformedPrimitiveBounds)).  Eventually, a considerable chunk of time is
> spent in the constructor of o.a.b.gvt.text.BidiAttributedCharacterIterator.  
> 
> There are quite a few interesting comments, as well as flow control statements
> in the constructor of that particular class that I was hoping Bella (@author) or
> Vincent (cvs checkin) could elaborate upon.  For instance, what would I do, if I
> didn't want to check for bidi text?

    Actually I think I'm the last one to do major work on this class.
The biggest time sink here is copying the AttributedString, this is
unfortunately required because java.awt.Font get's really upset if
you give it a an attribute map with 'null' values.  I looked at
removing the 'addition' of null values but I ran into problems
(it was a long time ago and I don't remember the exact details).

    There is a 'quick' out for non-bidi text - although it still does
bidi analysis.  If you wanted to just do the copy you could probably
do that.

    It is well known that this code is a bottleneck for text, and some
effort has been put into eliminating this (whith out much success
unfortunately).

>>>I enjoy the power of the library, but my only real problem is that it's
>>>slow. 
>>
>>>(1 second per image, 14 images / page.  The PrintTranscoder takes
>>> noticeably longer.)
>>
>>   What platform (OS/CPU roughly) are you running on?

> My development box is a Pentium 4 2.6GHz machine with 512mb of RAM.  I am
> running Windows XP.
> 
> 
>>>Is this speed normal?  
>>
>>   1 second per image seems slow to me.  Can you post sample content?
>>Is the 1sec for PNG output or PDF?  How large a PNG (pixels) are we
>>talking abount?

> I can't post sample content, but I may be able to send you an SVG and/or a PNG
> of my results, if you would like.  The images tend to be about 200 x 300 pixels,
>  4-6 per page (served up through a servlet)

    If you want to send it to me personally I'll take a look.  I'll be
away next week so don't expect a quick response.

>>>Are there ways to enhance the speed?  
>>
>>   As you might guess there is no magic -go-really-fast switch.
>>One is that PNG output is much slower than JPEG - I know that
>>JPEG is not ideal for graphs but it may be something to consider.
> 
> It's not so much the PNG output that I'm worried about, we can cache the images
> on the server effectively providing the user with a fast web experience.  The
> real bottleneck arises when a request has been made for a report in PDF.  The
> process attempts to transcode/print a large number of images (20) and takes
> about a second for each image.  In both cases (PNG and PDF), as I happened to
> notice earlier, the BidiAttrCharIter class appears to take up a good chunk of
> time.  I'm not sure if I'm on the right track, but I would prefer to spend some
> time in that class either tweaking the Bidi code, or turning it off completely.
> 
> 
>>>I would really like to increase performance.  
>>>Is this an appropriate use of the PrintTranscoder class?  
>>
>>   Well it seems a little hokey to me, I would write a new
>>transcoder subclass for the iText library.  If you look at
>>the existing transcoder examples it should give you a good
>>idea of how to do it.
> 
> 
> That's what struck me at first.  Would writing such a transcoder require
> intimate knowledge of the SVG and PDF spec?  Would I need to know the details of
> how the GVT works too?

    No not really.  In general it is mostly cut and paste from
the other transcoders with a few tweaks to align with the libraries
in use.

>>>Is there another way of writing an SVG to a Graphics object?  
>>
>>   Sure, all the image transcoders also "write an SVG to a Graphics
>>object".  You might also want to look at the pdf-transcoder that is
>>built into Batik (using code from FOP).
> 
> I've thought about using FOP, but the developers have listed implementation
> issues (http://xml.apache.org/fop/graphics.html) which have discouraged me from
> using it.  But I will keep this in mind.

    It is true that it isn't perfect but for graphs I would think
that it would work well.

>>>Should I be cautious about the usage of the PrintTranscoder in a
>>
>>multithreaded
>>
>>>environment?
>>
>>   You should be alright as long as you don't try and use the same
>>document/Graphics across threads.  But I don't know anything about
>>the iText library so perhaps it has problems internally.
>>
> 
> 
> Good to know.  But just to qualify:  say I were to launch 10
> PrintTranscoders/PNGTranscoders in 10 separate threads, there should not be any
> thread-related issues (no blocking or waiting on some shared resource), right?

    Not other than typical system bottlenecks.  There are a few things
shared across threads but they shouldn't be at all contentious.


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