Savino, Matt C wrote:
Doesn't XSLT ultimately need it's source XML in a DOM object to run?
Certainly not if you are talking about java processors. Moreover source
xml in DOM form often means wastefulness of memory and cpu since almost
every xslt processor always builds its own *optimized* input
That's really good to know. Thanks
Matt Savino
> > Doesn't XSLT ultimately need it's source XML in a DOM
> object to run?
>
> It depends. One point is that DOM is an interface, and there
> exist heavyweight and leightweight implementations. Some
> XSLT processors can work directly from an arb
Savino, Matt C wrote:
Create SAX events directly from the DB query result.
Doesn't XSLT ultimately need it's source XML in a DOM object to run?
It depends. One point is that DOM is an interface, and there
exist heavyweight and leightweight implementations. Some
XSLT processors can work directly
> Create SAX events directly from the DB query result.
Doesn't XSLT ultimately need it's source XML in a DOM object to run?
Matt Savino
Savino, Matt C wrote:
I meant to ask--what alternatives do you suggest to that avoidable second
step as far as getting to the XSLT processor?
Create SAX events directly from the DB query result. Unless
you have some non-trivial calculations or you know you can
benefit from caching, don't use entity
J:
> No offense meant, but most people start with the most
> inefficient ways to generate XML, usually doing a
> lookup in a remote database (which is slow, but hard to
> avoid), building an XML string or a DOM tree (which is
> slow, memory consuming and avoidable) and then feed it
> to the XSLT pr
J:
> No offense meant, but most people start with the most
> inefficient ways to generate XML, usually doing a
> lookup in a remote database (which is slow, but hard to
> avoid), building an XML string or a DOM tree (which is
> slow, memory consuming and avoidable) and then feed it
> to the XSLT pr
Zahigian, Mike wrote:
J., I am getting data out of some javabeans in the form of xml, then this
xml is transformed using a stylesheet, then another transformation takes
place to create the xsl:fo and then FOP takes over. I'll go ahead and try
and profile--you think the bottleneck might be in the t
CPU usage issue, I'm
not sure.
Matt Savino
> -Original Message-
> From: Savino, Matt C [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 06, 2002 2:17 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Performance Guidance
>
>
> I mean every o
I get it. Do you know if I can similarly limit the number of instances of a
servlet to one?
Mike Z.
-Original Message-
From: Savino, Matt C [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 06, 2002 2:17 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Performance Guidance
I mean e
f the details.
Matt Savino
> -Original Message-
> From: Zahigian, Mike [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 06, 2002 2:13 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Performance Guidance
>
>
> Matt, I'm not sure what you mean by
Sent: Thursday, June 06, 2002 1:51 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Performance Guidance
I am curently working on a system to only allow one FOP processing thread
per appserver instance. You can search my earlier posts for some
benchmarking results.
Matt Savino
Senior Systems
- 310-344-0889
pg - 949-452-4566
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 06, 2002 1:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Performance Guidance
>
>
> Zahigian, Mike wrote:
> > I am using FOP to take a
Zahigian, Mike wrote:
I am using FOP to take a single page of XSL:FO content and convert to PDF.
I have embedded FOP in a servlet. When I have one user requesting a page it
takes about 6 or 7 seconds to get the page formatted as PDF. It seems like
each additional simultaneous request pushes the r
14 matches
Mail list logo
