[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML Performance in a Transacation

• To: xml-dev@l...
• Subject: RE: XML Performance in a Transacation
• From: Tatu Saloranta <cowtowncoder@y...>
• 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@s...> 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 

• Prev by Date: Re: XML Performance in a Transacation
• Next by Date: RE: XML Performance in a Transacation
• Previous by thread: RE: XML Performance in a Transacation
• Next by thread: RE: XML Performance in a Transacation
• Index(es):
  • Date
  • Thread