You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Arved Sandstrom <Ar...@chebucto.ns.ca> on 2001/05/10 01:13:33 UTC

Re: performance problems

On Thursday 10 May 2001 00:50, Steve Cameron wrote:
> Hi all,
> I am making use of FOP in a production environment in two projects. In
> both cases I have come up against problems with memory requirements and
> the resulting "OutofMemoryError".
>
> >From my understanding of the way that FOP works I will be faced with
>
> this problem until such time as consideration is given to changing the
> way that .fo file processing occurs.

A number of us are in the high-level design phase right now, for improving 
processing. Although the intent is to simplify the code and allow us to 
complete features, the odds are that this re-design will permit easier 
optimization.

> I would like to request that someone in the development group give some
> thought to solving this this now rather than later otherwise my
> continued use of FOP will be unlikely as management is unlikely to
> support further use.

The issue has come up several times. In the final analysis the human resurce 
equation is pretty harsh - there are only so many developers (including 
committers), almost all of us (to the best of my knowledge) are part-time 
volunteers, and there is only so much we can do.

We had a show of hands a while back, and the consensus was: work on features. 
I can only speak for myself, and I have to agree with that. There isn't a 
single developer here, I'll bet, who wouldn't like to optimize, but it has 
got to wait until we have our target feature set coded and tested.

We are attempting to do the re-design so that performance improvements will 
be relatively easy to make. But the actual coding on those performance 
enhancements is a ways down the road, unless a developer steps in and wants 
to work on that specifically.

> I have not studied the FOP java code but would like to suggest an option
> that would work in my situation, that is to have the option to process a
> FOP file by successive <page-sequence> .... </page-sequence> groups.
> That is by successive read_fop->render->write_pdf cycles based on the
> occurence of the <page-sequence> tags. I can easily insert
> <page-sequence> tags at regular intervals into the .fo file as the
> documents I am generating consist of discreet single pages or successive
> tables of data.

Is there any reason why you cannot achieve the same effect with a shell 
script that bundles up sets of pages that you know will not lead to an 
OutOfMemory problem, and completes the separate FO files so that you can run 
them, with an automatic update of the page number in the <fo:page-sequence> 
as required (also supplied by the script)?

This is something that you could do right now. If your documents are really 
composed of essentially independent pages I am not sure but that this would 
essentially be as good a solution as what you suggest above. At least for the 
interim.

> I would appreciate a response from the FOP developers on this as I am
> faced with a difficult decision and having invested some time in FOP and
> also wanting to progress with XML in general I am reluctant to abandon
> it to soon. I would be willing to invest some time in helping to create
> a solution but my java skills are rudimentary at present.

Not to get your hopes up but we may see a contributed solution within a few 
weeks. Failing that, I can only reiterate that I personally take performance 
seriously, and if it wasn't for the fact that FOP is still development 
software (not even alpha or beta) I'd be working on that right now.

> Comments from other FOP users facing the same issue a welcomed as well.
> Thanks
> Stephen Cameron ( Systems Support Analyst, Fortis Clearing Sydney )

Regards,
Arved Sandstrom

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