Hi Mork, Mork0075 <[EMAIL PROTECTED]> wrote on 10/04/2007 06:38:04 AM:
> i've had the same feeling, that the time per transformation decreeses > with the number of transformations in batch. But this doesnt help the > users who alsways transform only one or two svgs at once. In a typical production environment this would be hosted in a long running "service" like a Java Servlet host (Tomcat). This allows the JVM to be up and running and for the Java code to be already Compiled to Native code (JIT). > Would it be helpful to send you the svg file, so you can have a look if > there are any constructs which causes the lack? It might, but it isn't likely I'd have time to look at it for a while... > [EMAIL PROTECTED] schrieb: > > > > Hi Mork, > > > > Mork0075 <[EMAIL PROTECTED]> wrote on 09/13/2007 02:57:21 AM: > > > >> For a (for me) simple SVG to PDF transcoding, the PDFTranscoder took > >> about 3sek and uses almost the whole cpu time. I would like to use the > >> batik technologie in a productive environment and i think this can > >> become a problem if multiple users transcode more then 1 pdf at the same > >> time. > >> > >> Do you have any suggestions how to speed up the process? Or is the > >> PDFTranscoder even the right solution for my needs? > > > > Well if you want to go SVG -> PDF it's probably your best bet. > > As to how to speed things up the amount of time required is almost > > entirely dependent on the content being transcoded. > > > > Also it's worth noting that a lot of time can be eaten up > > starting the JVM, so to get a better feel for the real time to > > transcode you should convert several SVG's at one time and divide > > the entire time by the number of SVGs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
