[
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: Fri, 24 Mar 2006 12:39:03 -0800 (PST)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J1ynOyzcARiylylyRu21WbujUjs3uxFI8ehoatdri3TvGAbWQp8mRuCGhbI6BKV1JgO0ab1FNo1QpH+6AEZuPhk9lqlpvRFlnkNVE4TaskT7lgZCKF6el/+JhJotU42fYepbbiHwvuDBroGyYGyZ9fReZvrW1ojNpsC6OCY5jH4= ;
--- Michael Kay <mike@saxonica.com> wrote:
> XSLT processing isn't O(n^2) either. Many
> transformations run in linear
> time. Of course it's very easy for a user to write
> XSLT applications that
> are O(n^2) or worse - and it would be wrong to make
> it difficult!
Hmmmh. Would it? It would be great if, of functionally
equivalent choices, it would be more intuitive and
easier to choose the one with better performance
characteristics (in cases where it matters). That is,
to try to avoid making "wrong" choices too tempting.
I assume XSLT usage has many parallels to SQL usage --
in both cases there are lots of ways of using things
more efficiently. Just as with parsing, getting more
information on clean efficient usage patterns would go
a long way towards better actual end-to-end
performance.
-+ Tatu +-
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
