xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Forget, Pascal" <pascal.for...@cgey.com>
Subject RE: Why is FOP MUCH slower the first time than all other runs?
Date Fri, 06 Feb 2004 21:30:29 GMT

Or you can start tomcat and leave it on...

-----Original Message-----
From: George Yi [mailto:gyiii@srds.com]
Sent: Friday, February 06, 2004 4:19 PM
To: fop-user@xml.apache.org
Subject: RE: Why is FOP MUCH slower the first time than all other runs?


One way to work around, you can write an init servlet to load these jars
when you start Tomcat. Of cause these will increase Tomcat startup time.

-----Original Message-----
From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
Sent: Friday, February 06, 2004 3:12 PM
To: fop-user@xml.apache.org
Subject: Re: Why is FOP MUCH slower the first time than all other runs?

Robert Paris wrote:
> I don't think it's the tomcat issue, it takes a long time the first
time
> even when I call it from a java class (if the class creates a pdf then

> creates another one before exiting, the second one is much faster).
It's
> got to be in the FOP. Is there a way to fix this?

1. It has to load all the classes from the jars.
2. Some static data is set up while loading classes, for example
  the tables mapping the FO names to factories. There's a lot of
  object creation and such going on at this time.
The current implementation has certainly room for improvement.
Several ideas have been discussed, here as well as for other
software facing similar problems. Unfortunately, Java doesn't
allow for really static memory initialization like C/C++ does,
which, together with the lack of plain function pointers, makes
further optimization of the mapping tables somewhat difficult.

If you have ideas, please post.

Well, the static data as well as various instance data is quite
often initialized too eagerly. I'll be indebted to anyone who
scrutinizes the whole setup for places where postponing creating
a variety of ArrayLists and HashTables is a win. IIRC in the
example I used for tracking down the table area problems there
were 800000 HashTables created, of which only 200000 ever saw an
element put into it (the average number of elements for hash
tables with at elast one element was less than 1.2).

J.Pietschmann

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




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


___________________________________________________________________________
 This message contains information that may be privileged or confidential
 and is the property of the Cap Gemini/Ernst & Young Group.  It is intended
 only for the person to whom it is addressed.  If you are not the intended
 recipient, you are not authorized to read, print, retain, copy,
 disseminate, distribute, or use this message or any part thereof. If you
 receive this message in error, please notify the sender immediately and
 delete all copies of this message.
___________________________________________________________________________

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


Mime
View raw message