Performance Questions
Is there a performance advantage to using bucket brigades vs. just "printing" to the request object? I assume the latter uses the former at some level. I have a PerlResponseHandler feeding into a PerlOutputFilterHandler. The latter uses bucket brigades directly for both input and output. The former just prints to the request object. I was wondering if I should fix the PerlResponseHandler to use bucket brigades directly, or if it really mattered. The other side of this is that the response handler generates XML and the output filter handler consumes it. I was thinking that I should be able to hang the XML object (not the text representation thereof) on the request object and avoid the overhead of printing the XML and then parsing it again. Has anyone tried doing this? Marc M. Adkins
Re: Performance Questions
Marc M. Adkins wrote:
The other side of this is that the response handler generates XML and
the output filter handler consumes it. I was thinking that I should
be able to hang the XML object (not the text representation thereof)
on the request object and avoid the overhead of printing the XML and
then parsing it again. Has anyone tried doing this?
I've no experience of parsing XML on every request (not that I'd want
to, what an overhead!) but could you just output nothing in the response
phase, and put the XML object reference using
$r->pnotes('my_xml_object', $my_xml_object) then in your output filter
do $my_xml_object=$r->pnotes('my_xml_object') ?
cheers
John
Re: Performance Questions
--- John ORourke <[EMAIL PROTECTED]> wrote:
> I've no experience of parsing XML on every request
> (not that I'd want
> to, what an overhead!) but could you just output
> nothing in the response
> phase, and put the XML object reference using
> $r->pnotes('my_xml_object', $my_xml_object) then in
> your output filter
> do $my_xml_object=$r->pnotes('my_xml_object') ?
>
That's exactly what I would do. In fact you may be
able to avoid generating and parsing the XML
altogether, and just use a regular Perl object
instead. That is unless the data represented as XML
would lose something by not *being* XML.
Regards,
John Drago
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
Re: Performance Questions
Well, I _am_ using XSLT for my template expansion. That kind of makes
XML important.
Thanks for the responses, and that's about what I figured I would try.
Just wondering if anyone would answer "no it won't work because..."
John Drago wrote:
--- John ORourke <[EMAIL PROTECTED]> wrote:
I've no experience of parsing XML on every request
(not that I'd want
to, what an overhead!) but could you just output
nothing in the response
phase, and put the XML object reference using
$r->pnotes('my_xml_object', $my_xml_object) then in
your output filter
do $my_xml_object=$r->pnotes('my_xml_object') ?
That's exactly what I would do. In fact you may be
able to avoid generating and parsing the XML
altogether, and just use a regular Perl object
instead. That is unless the data represented as XML
would lose something by not *being* XML.
Regards,
John Drago
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
Re: Performance Questions
Marc M. Adkins wrote: Well, I _am_ using XSLT for my template expansion. That kind of makes XML important. Thanks for the responses, and that's about what I figured I would try. Just wondering if anyone would answer "no it won't work because..." Let us know how it goes - using XSLT that way is often desirable from a developer's point of view, but is usually impractical due to the processing overhead. If you end up successfully using this technique in production without complaints from users please let the list know, I'm sure a few other people are curious too! cheers John
Re: Performance Questions
Let us know how it goes - using XSLT that way is often desirable from a developer's point of view, but is usually impractical due to the processing overhead. If you end up successfully using this technique in production without complaints from users please let the list know, I'm sure a few other people are curious too! Just a personal opinion: wouldn't xslt juice out the cpu faster than a conventional template engine (eg. HTML::Template)? If you are running a fairly high-use environment, you may want to implement stuff that is easy on the processor. Thinking aloud though, perhaps if the xslt engine caches the compiled xslt file, performance may improve...
