Performance PDFRenderer vs. PCLRenderer

[Michael Reiche <re...@image.dk>]

I use an embedded version of FOP, primarly to keep the Java "hot"
getting benefit from JIT. PCL-output is top priority rather than PDF.
But I face the problem that the PCL-renderer is rather slow compared to
the PDF-renderer (which my initital testing was based on ).

I feed FOP with an XSL-FO document, which in this test generates 7 pages
(source is 176464 bytes). The document contains in-stream SVG-graphics,
which the PCL-renderer completly ignores - thats another challenge. Its'
running in Java1.4.2 on Linux in a headless environment.

Timing of the 6 first runs of the same document, each  sequence starting
from a new  "cold" Java VM, is like this:

PDF:

1. 10606 millis.
2. 1773 millis.
3. 1731 millis.
4. 1533 millis.
5. 1707 millis.
6. 1601 millis.

PCL:

1. 14312 millis.
2. 14077 millis.
3. 14242 millis.
4. 14126 millis.
5. 14111 millis.
6. 14018 millis.

Notice that the PDF-renderer just needs 1 run to benefit from JIT, but
the PCL-renderer neverer improves performance. It should be noted that
the server running the Java VM is doing nothing besides my tests.

A note regarding the PCL-rendering: starting with the 2. run the first 3
or 4 pages renders quickly, but then a complete slowdown occurs. This
could indicate massive garbage collection or.....?

I've had my eyes on both PDFRenderer.java and PCLRenderer.java, but I
haven't been able to spot that magic difference. Could it be that the
PDF-renderer has suffered from the same performance-problem, and someone
remembers how it was improved, or otherwise has some tips to improve the
PCL-renderer?

-- 
/Reiche



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

RE: Performance PDFRenderer vs. PCLRenderer

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Michael Reiche [mailto:reiche@image.dk]
>
> I use an embedded version of FOP, primarly to keep the Java "hot"
> getting benefit from JIT. PCL-output is top priority rather than PDF.
> But I face the problem that the PCL-renderer is rather slow compared to
> the PDF-renderer (which my initital testing was based on ).
>
> I feed FOP with an XSL-FO document, which in this test generates 7 pages
> (source is 176464 bytes). The document contains in-stream SVG-graphics,
> which the PCL-renderer completly ignores - thats another challenge. Its'

Well, the FOP Output Targets page (http://xml.apache.org/fop/output.html)
does indicate that SVG support for the PCL Renderer is somewhat limited.
This shows itself in the source, I guess, where the PDFRenderer contains
import statements for the Batik bridges as well as a reference to the
java.awt.geom lib (as opposed to the PCLRenderer). If you really want to
have a go at extending the PCLRenderer to offer the same support as the
PDFRenderer, I think this is your starting-point.
Explanation for this probably lies in the fact that Batik offers direct
SVG2PDF conversion via its Rasterizer (which in turn uses FOP's
PDFTranscoder), so every once in a while, members of the Batik dev-team or
Batik users happily provide FOP with a few patches to enhance the SVG
support when rendering to PDF.

> running in Java1.4.2 on Linux in a headless environment.
>
> Timing of the 6 first runs of the same document, each  sequence starting
> from a new  "cold" Java VM, is like this:
>
<snip/>
>
> Notice that the PDF-renderer just needs 1 run to benefit from JIT, but
> the PCL-renderer neverer improves performance. It should be noted that
> the server running the Java VM is doing nothing besides my tests.
>

I'm not too well-informed about the particulars of JIT, but the PDFRenderer
*is* the most advanced Renderer offered by FOP. Maybe a redesign of the
PCLRenderer modeled according to the current PDFRenderer could improve
performance in this way. ( I, for one, would be *very* curious to see how
the Batik team would respond to a full-fledged PCLTranscoder ). Currently
the PCLRenderer consists solely of a PCLRenderer and a PCLStream, whereas
the PDFRenderer has a whole lib (org.apache.fop.pdf)
at its disposal, allowing for a more controlled and detailed optimization.

> A note regarding the PCL-rendering: starting with the 2. run the first 3
> or 4 pages renders quickly, but then a complete slowdown occurs. This
> could indicate massive garbage collection or.....?
>

Could be... Have you tried changing the size of the JVM heap? If that has an
impact, this would indeed be what is happening over here.

> I've had my eyes on both PDFRenderer.java and PCLRenderer.java, but I
> haven't been able to spot that magic difference. Could it be that the
> PDF-renderer has suffered from the same performance-problem, and someone
> remembers how it was improved, or otherwise has some tips to improve the
> PCL-renderer?

Browsed through the fop-dev list searching for this, but haven't yet found
traces of previous discussions about this. I have noticed that the
PCLRenderer was donated to FOP, whereas the PDFRenderer was there from the
very start. My guess would be that, initially it was more of a
convenience-addition, allowing to skip the intermediate generation of a
(physical) PDF and send the output directly to the PCL printer ( same goes
for the PS Renderer ).

Suggestion would be to study the PDF rendering process very closely, and try
to 'mimic' it in terms of PCL, maybe this gets you on track ...?

And of course, when you *do* decide to make changes like this, and they turn
out to work properly and improve performance, don't forget to let us know
about this :)


Hope these help!

Greetz,

Andreas


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