________________________________
> Date: Thu, 4 Mar 2010 10:16:30 -0800
> From:
> To: itext-questions@lists.sourceforge.net
> Subject: [iText-questions] Performance improvement to PdfGraphics2D
>
>
>
>
>
>
>
>
>
>
> Hello,
>
>
>
> I was using iText to convert a JTable to a PDF. This was consuming a
> large amount of memory and taking a long time, so I did some memory
> profiling and have attached a patch that significantly improves
> performance for us. The following describes what I found, and what the
> patch does:
>
> When printing a JTable, you have to construct a lot of
> child PdfGraphics2D objects. For each child, the following happens:
>
>
> 1. A BufferedImage is created just so that we can get a regular
> Graphics2D. This Graphics2D object may never be used, so I patched
> PdfGraphics2D to construct it only if needed.
But ctor calls are order-0 ( humour). Yes, garbage generation can be a big deal
and beside the ultimate GC problems that may not show up on profiling ( when
the
GC thread executes it doesn't show up in your stack trace), initialization code
can take forever because, well, everything is initialized including large
arrays ( you don't get initialized memory for free even if it is still one line
of source code) etc.
Usually you see warnings about this with string manipulations
since temps aren't always appreciated and can become significant in a hurry.
I also remember being shocked at the start up time in some apps that
were cleaned up to be more OO- I'm really not sure if anyone cares about init
resources... In C++ there is some hope compiler can fix a lot
of OO overhead but things are worse in java.
Once terms like "graphics" start to appear, the attention goes to inner
loops and cool terms related to getting pixels onto the screen. With
java, the optimization in this native code can make all the surrounding
stuff an important time sink.
>
>
> 2. Two arrays of PdfGState are created, but are then replaced with
> the parent's arrays. I patched PdfGraphics2D to create these arrays in
> the non-private constructor. You might want to consider using the
> clone() method instead of keeping that private constructor around. The
> normal .clone() behaviour is very similar to what you have done
> manually in the .create() method.
>
>
>
> Finally, I noticed that the AWT PathIterator.currentSegment(float[])
> method creates a double[] internally. That is because the float[]-based
> method just passes through to the double[]-based method. I modified
> your use of the PathIterator to take this into account.
>
>
> Can this patch be included in the next release?
>
>
>
> Also, I am working on a commercial product. Can you clarify for me
> whether or not iText PDF can be included as a .jar in our commercial
> (non-open-source) product? I cannot remember whether "using a .jar" is
> considered a derivative work or not. If we're allowed to use it, then I
> will probably do a little more work on improving performance of iText
> and will send that on.
>
>
>
> Thanks,
>
> Peter.
>
>
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.1t3xt.com/docs/book.php
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
