[
Lists Home |
Date Index |
Thread Index
]
Rick Marshall 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.
So what?
Where is the O(N^2) code in the UTF-8 converter? Encoding converters are
regularly stated as the source of bottlenecks. (Of course any serious
developer will look at the order of the algorithm: Rick is being prudent
and correct, but you don't solve problems by denying them!)
> big documents will degrade badly - and this is the real thing to beat
> - not simply raw speed.
And that is the point of a contest. Instead of windbagging in vague
generalities, developers can write code that actually tests and proves
their (including my!) theories.
Last year I think there were reports of good speed ups in parsing in
Java jsut from re-using SAX objects. (I think the research was academic
from Eastern Europe, sorry no references.) Good work. Corporate users of
XML open source processors (and commercial processors too!) need to
stimulate research and development of techniques and open source code,
from all angles.
XML is not a technology optimized for maximum throughput: indeed its
development goal of "terseness is of minimal importance" means that it
may be regarded as a technology optimised for mediocre throughput! It
needs R&D, open source and benchmarking to improve the state of the
basic processing stack to make it a better, cheaper fit for high-volume
systems than it is now.
Cheers
Rick
|
