Home » Archived » BIRT » Any concerns with XSL:FO performance/scalability?
| Any concerns with XSL:FO performance/scalability? [message #2789] |
Tue, 11 January 2005 11:20  |
Eclipse User |
|
|
|
Originally posted by: csetera.spss.com
Hello,
In a recent newsgroup posting, Paul Rogers noted "BIRT uses XML FO for
print and PDF output. FO will do pagination based on the font
information available on the particular machine, on the resolution of
the printer, etc. In general, BIRT can't guess ahead of time what that
pagination will be, and so can't create page-specific totals."
In some previous research, some folks from my development group had
taken a look at Apache's FOP and the RenderX processor. In both cases,
the performance was poor for a reasonable sized document. Also, there
were concerns about the memory usage while processing these documents
and whether that would lead to any scalability problems during rendering.
Are there any concerns with using this approach within BIRT? Will BIRT
be using a currently available FO processor that could be pretested for
performance and scalability? Will the FO processor be pluggable? What
will be the conformance requirements for the FO processor in order to be
able to render BIRT reports?
Thanks,
Craig
Master Software Engineer, SPSS, Rochester MN
Sun Certified Java Programmer, Developer and
Web Component Developer
|
|
|
| Re: Any concerns with XSL:FO performance/scalability? [message #2983 is a reply to message #2789] |
Fri, 14 January 2005 13:26  |
| Eclipse User |
|
|
|
Originally posted by: jimreesman.yahoo.com
I'll echo Craig's concerns. We found FOP to be unacceptable for
interactive document rendering for any but the smallest documents. (Our
users were routinely creating 100-1000+ page reports.) At the time there
was some discussion of a 'complete redesign/rewrite' of FOP to address
performance and scalability. I haven't followed the progress since then,
so I can't comment further. Of course RenderX, although it's performance
was better, had (at the time) fairly significant license and license
cost implications. Our intended strategy of leveraging FO as a
convenient intermediate form was dropped as a result.
Jim
Craig Setera wrote:
> Hello,
>
> In a recent newsgroup posting, Paul Rogers noted "BIRT uses XML FO for
> print and PDF output. FO will do pagination based on the font
> information available on the particular machine, on the resolution of
> the printer, etc. In general, BIRT can't guess ahead of time what that
> pagination will be, and so can't create page-specific totals."
>
> In some previous research, some folks from my development group had
> taken a look at Apache's FOP and the RenderX processor. In both cases,
> the performance was poor for a reasonable sized document. Also, there
> were concerns about the memory usage while processing these documents
> and whether that would lead to any scalability problems during rendering.
>
> Are there any concerns with using this approach within BIRT? Will BIRT
> be using a currently available FO processor that could be pretested for
> performance and scalability? Will the FO processor be pluggable? What
> will be the conformance requirements for the FO processor in order to be
> able to render BIRT reports?
>
> Thanks,
> Craig
>
> Master Software Engineer, SPSS, Rochester MN
> Sun Certified Java Programmer, Developer and
> Web Component Developer
|
|
|
| Re: Any concerns with XSL:FO performance/scalability? [message #4357 is a reply to message #2983] |
Wed, 19 January 2005 14:04 |
| Eclipse User |
|
|
|
Jim & Craig,
Thanks for the head's up. Using FOP for the first release allows us to
focus on other areas of report generation and rendering. At the same time,
performance is a key goal. We're running tests to get a good sense of the
actual issues. XSL:FO is a convenient way to handle conversion and be
standards-compliant -- if it works. As a result, we intend to generate FO
that follows CSS standard. However, since FOP does not support many
features for now, we also allow generation FO that contains some
workarounds so that the FOP output makes more sense.
The Engine is designed to allow extended converters, so we/others can plug
in a better converter easily if/when needed.
In the first release, reports are on demand and in a single web page, so
are expected to be small. In a subsequent release, reports will be stored
on disk and can be any size. That will be an excellent time to determine
if we need to reconsider our conversion strategy. One approach is to
directly go from report design to PDF, as someone already suggested in the
newsgroup.
Thanks. --Stanley
Stanley Wang
Actuate Corp.
BIRT project lead
Jim wrote:
> I'll echo Craig's concerns. We found FOP to be unacceptable for
> interactive document rendering for any but the smallest documents. (Our
> users were routinely creating 100-1000+ page reports.) At the time there
> was some discussion of a 'complete redesign/rewrite' of FOP to address
> performance and scalability. I haven't followed the progress since then,
> so I can't comment further. Of course RenderX, although it's performance
> was better, had (at the time) fairly significant license and license
> cost implications. Our intended strategy of leveraging FO as a
> convenient intermediate form was dropped as a result.
> Jim
> Craig Setera wrote:
>> Hello,
>>
>> In a recent newsgroup posting, Paul Rogers noted "BIRT uses XML FO for
>> print and PDF output. FO will do pagination based on the font
>> information available on the particular machine, on the resolution of
>> the printer, etc. In general, BIRT can't guess ahead of time what that
>> pagination will be, and so can't create page-specific totals."
>>
>> In some previous research, some folks from my development group had
>> taken a look at Apache's FOP and the RenderX processor. In both cases,
>> the performance was poor for a reasonable sized document. Also, there
>> were concerns about the memory usage while processing these documents
>> and whether that would lead to any scalability problems during rendering.
>>
>> Are there any concerns with using this approach within BIRT? Will BIRT
>> be using a currently available FO processor that could be pretested for
>> performance and scalability? Will the FO processor be pluggable? What
>> will be the conformance requirements for the FO processor in order to be
>> able to render BIRT reports?
>>
>> Thanks,
>> Craig
>>
>> Master Software Engineer, SPSS, Rochester MN
>> Sun Certified Java Programmer, Developer and
>> Web Component Developer
|
|
|
| Re: Any concerns with XSL:FO performance/scalability? [message #6059 is a reply to message #4357] |
Mon, 24 January 2005 16:39 |
| Eclipse User |
|
|
|
Originally posted by: csetera.spss.com
Stanley,
Thanks for your thoughts on this. I certainly understand and appreciate
your goal of being standards compliant with these files.
I spent some time taking a look at a recent FOP 1.0 nightly developer
snapshot to get a feel for just how well it will work. I had pretty
mixed results in the end. From a pure speed perspective, things didn't
seem to bad. I was seeing reasonable rendering speed as long as the
report didn't get too long. Unfortunately, the rendering does not scale
well at all. It appears that FOP is attempting to build a complete
in-memory object representation of the XSL:FO document before even
beginning a rendering of the document. This ends up causing
OutOfMemoryError's once the input document begins to get larger. I was
able, by handing the JVM 512M to do the rendering to get through a table
with 8K rows of data (5 columns), but taking it to 16K rows just wasn't
possible.
It appears that FOP is going to require a massive redesign in order to
be able to support larger reports such as these. What is the plan for
rendering after release 1 if FOP can't cut it? Are there any thoughts?
On a related note, can you talk at all about what the rendering plugins
might look like in place of FOP?
Thanks,
Craig
Stanley Wang wrote:
> Jim & Craig,
>
> Thanks for the head's up. Using FOP for the first release allows us to
> focus on other areas of report generation and rendering. At the same
> time, performance is a key goal. We're running tests to get a good sense
> of the actual issues. XSL:FO is a convenient way to handle conversion
> and be standards-compliant -- if it works. As a result, we intend to
> generate FO that follows CSS standard. However, since FOP does not
> support many features for now, we also allow generation FO that contains
> some workarounds so that the FOP output makes more sense.
> The Engine is designed to allow extended converters, so we/others can
> plug in a better converter easily if/when needed.
>
> In the first release, reports are on demand and in a single web page, so
> are expected to be small. In a subsequent release, reports will be
> stored on disk and can be any size. That will be an excellent time to
> determine if we need to reconsider our conversion strategy. One approach
> is to directly go from report design to PDF, as someone already
> suggested in the newsgroup.
>
> Thanks. --Stanley
>
> Stanley Wang
> Actuate Corp.
> BIRT project lead
>
|
|
|
| Re: Any concerns with XSL:FO performance/scalability? [message #6228 is a reply to message #6059] |
Mon, 31 January 2005 17:12 |
| Eclipse User |
|
|
|
Craig,
Thanks for the investigation on FOP performance. Our focus for the first
release is to create a robust report object model, to build a solid report
creation framework, to allow reasonable rendering, to handle customization
through scripting, and to support extensions through plugins in a
server-based environment. To achieve such goals in a reasonable
time-frame, we have chosen to delegate detailed rendering to browser (for
HTML format) and to XSL-FO processor (for PDF). Your feedbacks for our
choice are precious for our decisions toward future releases of BIRT.
Performance will likely be a priority after release one. We already have
discussions on by-passing XSL-FO and directly rendering reports to various
output formats, though we do not have a concrete plan yet. We also hope
that BIRT may generate more interests in the FOP project, so that the
issues you brought up may be addressed by FOP.
In terms of the rendering process, we will soon have a code drop. We may
still make changes to some interfaces, though. To give a brief summary,
the report engine has executors that support the reporting logic. For each
report item instance it creates, the executor calls into a pluggable
emitter which handles the generation of specific XSL-FO content. The
emitter implements functions such as startText, endText, startImage,
endImage, etc.
Thanks. --Stanley
Stanley Wang
BIRT Report Engine Project Lead
Craig Setera wrote:
> Stanley,
> Thanks for your thoughts on this. I certainly understand and appreciate
> your goal of being standards compliant with these files.
> I spent some time taking a look at a recent FOP 1.0 nightly developer
> snapshot to get a feel for just how well it will work. I had pretty
> mixed results in the end. From a pure speed perspective, things didn't
> seem to bad. I was seeing reasonable rendering speed as long as the
> report didn't get too long. Unfortunately, the rendering does not scale
> well at all. It appears that FOP is attempting to build a complete
> in-memory object representation of the XSL:FO document before even
> beginning a rendering of the document. This ends up causing
> OutOfMemoryError's once the input document begins to get larger. I was
> able, by handing the JVM 512M to do the rendering to get through a table
> with 8K rows of data (5 columns), but taking it to 16K rows just wasn't
> possible.
> It appears that FOP is going to require a massive redesign in order to
> be able to support larger reports such as these. What is the plan for
> rendering after release 1 if FOP can't cut it? Are there any thoughts?
> On a related note, can you talk at all about what the rendering plugins
> might look like in place of FOP?
> Thanks,
> Craig
> Stanley Wang wrote:
>> Jim & Craig,
>>
>> Thanks for the head's up. Using FOP for the first release allows us to
>> focus on other areas of report generation and rendering. At the same
>> time, performance is a key goal. We're running tests to get a good sense
>> of the actual issues. XSL:FO is a convenient way to handle conversion
>> and be standards-compliant -- if it works. As a result, we intend to
>> generate FO that follows CSS standard. However, since FOP does not
>> support many features for now, we also allow generation FO that contains
>> some workarounds so that the FOP output makes more sense.
>> The Engine is designed to allow extended converters, so we/others can
>> plug in a better converter easily if/when needed.
>>
>> In the first release, reports are on demand and in a single web page, so
>> are expected to be small. In a subsequent release, reports will be
>> stored on disk and can be any size. That will be an excellent time to
>> determine if we need to reconsider our conversion strategy. One approach
>> is to directly go from report design to PDF, as someone already
>> suggested in the newsgroup.
>>
>> Thanks. --Stanley
>>
>> Stanley Wang
>> Actuate Corp.
>> BIRT project lead
>>
|
|
|
Goto Forum:
Current Time: Fri May 09 11:21:45 EDT 2025
Powered by FUDForum. Page generated in 0.03397 seconds |
Home