Re: [soaplite] Using a parser other than XML::Parser or XML::Parser::Lite
> I don't think that you can (easily) change the parser used byIt should be easy, shouldn't it? As far as I remember,
gives you a current one and
replaces it with a new one.
Unfortunately, MySuperFastParser has to support Expat callback
interface (and LibXML does SAX), which may not be a problem given
available SAX to Expat modules.
It's unlike though that the parser is your bottleneck; probably it's
a combination of SOAP::SOM and the code you're using. You may get a
better result by converting the result of parsing into a suitable
Perl data structure and using it rather than a series of SOAP::SOM
Best wishes, Paul.
--- Duncan Cameron <duncan_cameron2002@...> wrote:
> On 13-05-2004 at 19:22:47 teden <thom@...> wrote:
> >I've got a pretty complex xsd/wsdl definition for my web service
> >which is running SOAP::Transport::HTTP::Daemon. The input schema
> >defines several layers of nesting arrays (arrays of arrays of
> >arrays). On the server side I am parsing it using SOAP::SOM using
> >variety of $som->dataof() calls nested inside of each other. I
> >optimized the code as best I can and server response time is still
> >the 6+ second range.
> >From majordojo (http://www.majordojo.com/soaplite/), I see a
> >that changing the XML parser can have a significant performance
> >(see article http://www.majordojo.com/archives/000150.php#000150).
> >OK, I'll bite... How do you change the behavior of SOAP::Lite to
> >a parser different from XML::Parser or XML::Parser::Lite? Given
> >XML::LibXML seems to be the fastest, I'd like to use it, bu don't
> >know where to begin to do that.
> I don't think that you can (easily) change the parser used by
> What I think is being referred to is extracting the XML content of
> the message and then using a different parser to parse and process
> On the article you refer to, the benchmark figures were posted by
> myself, not by Randy Ray. I cannot find the code at present but I
> am sure that the approach was as I mention above.
> ------------------------ Yahoo! Groups Sponsor
> Yahoo! Groups Links
- If you control both the client and the service, you could base64 encode
the content, then it wont be parsed...
This works surprisingly well!! ... if you are in total control at both
On Fri, 2004-05-14 at 13:11, thom@... wrote:
> Yes, I know about ->outputxml()... But I need it in the server. My
> problem is
> the service trying to extract all of the data from the envelope. It'd
> be great
> if you could set some parm when starting the service that inside the
> call you want the raw xml.
> This E-Mail was sent with Fronthost Web/Mail.
> Use www.fronthost.com for all your hosting and development needs.
> Yahoo! Groups Sponsor
> click here
> Yahoo! Groups Links
> * To visit your group on the web, go to:
> * To unsubscribe from this group, send an email to:
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Mark Wilkinson (mwilkinson@...)
University of British Columbia iCAPTURE Centre
- On 14-05-2004 at 19:59:45 Paul Kulchenko <paulclinger@...> wrote:
>> I don't think that you can (easily) change the parser used byThat's what I really meant. It is the accessing of the parsed data tree that may be the bottleneck , and using a different parser would give a structure that could be accessed more easily/quickly ...
>It should be easy, shouldn't it? As far as I remember,
>gives you a current one and
>replaces it with a new one.
>Unfortunately, MySuperFastParser has to support Expat callback
>interface (and LibXML does SAX), which may not be a problem given
>available SAX to Expat modules.
>It's unlike though that the parser is your bottleneck; probably it's
>a combination of SOAP::SOM and the code you're using.
- On 14-05-2004 at 18:14:21 Tod Harter <tharter@...> wrote:
>I have to say it would REALLY make things nicer if we could useI think that there may be (at least) two areas to look at
>XML::LibXML (in particular) as a parsing engine, its something on the
>order of 50 to 100 times faster, and the API is definitely quite a lot
>more standards-compliant and featureful. I'm wondering how hard it would
>be to abstract out an interface to allow SOAP::Lite internals to handle
>different parsers. Probably not easy, but on the last project I
>completed using SOAP::Lite parsing consumes on the order of 60% of all
>CPU cycles, eek!
Firstly, using, say, SAX2 callbacks would allow any SAX2 parser to be used. This I would guess is straightforward based on Paul's comment to my previous posting.
Secondly, building a result tree that can be accessed using full XPath notation, rather than or as well as the current SOM approach. This looks to be a bit more difficult.