[
Lists Home |
Date Index |
Thread Index
]
- To: xml-dev@lists.xml.org
- Subject: Re: [xml-dev] XML Performance in a Transacation
- From: Tatu Saloranta <cowtowncoder@yahoo.com>
- Date: Thu, 23 Mar 2006 21:44:30 -0800 (PST)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=APyfyFMHyXVnHgyORtROZvaumCQ3IvtnNmI3hHWKIL/AAyIqeQH9GULnKOhQoZOhpmqMegjUULvwIy7vRc1YV/U/xIeTO1bvkXhfCpDk3gmXPnVQ8PwgDHpaCX0GUuqRTYBwmceHC3YdhD2WovUKDjDB6qfLtb/LEhSqE32dXY4= ;
- In-reply-to: <442382C8.9030906@zenucom.com>
--- Rick Marshall <rjm@zenucom.com> wrote:
> can we just go back a minute - raw speed is not the
> only issue, it is
> the way in which the it degrades. o(n2) (order n
> squared) performance
> will always be bad, just faster bad.
>
> big documents will degrade badly - and this is the
> real thing to beat -
> not simply raw speed.
For this part, one needs to figure out which part of
the processing stack causes this. With bigger document
sizes parsing does not exhibit such behaviour,
although construction of in-memory models may (and
probably has to, to explain why Soap processing a la
Axis 1.x chokes with bigger message sizes).
But as likely it is the actual processing on that
model (XSLT and similar) that does it, and there it is
likely to be algorithmic problem (whether inherent to
xslt[-like] approach or not). And ways to improve this
part of the problem is quite different from dealing
with lower level aspects.
-+ Tatu +-
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
