[
Lists Home |
Date Index |
Thread Index
]
don't get me wrong - efficiency is important, i should know - it took me
10 years to get my database working fast enough, but what i'm saying is
it's irrelevant if the project doesn't work first.
in software engineering terms, bubble sort is a lousy mechanism, but it
works (and you'd be amazed at just how many hackers still use it). once
we knew sorting works we could develop better mechanisms - and quick
sort remains the staple of in memory sorting - because it's
mathematically as good as it gets - and it's heaps (excuse the pun)
better.
right now we know xml parsing works, even though we often complain about
the speed. now we need to understand better the mathematics of parsing
xml and then we can make the parsing work better.
if we want to throw it out then someone should come up with the maths
and prove it will never be parsed very fast and then we can all say,
well it was a good idea.. and move on.
i'm about to do some work on this, for my own selfish reasons, but if
the list is interested i'll gradually publish results.
rick
On Mon, 2003-09-22 at 04:07, Rick Jelliffe wrote:
> Rick Marshall wrote:
> > i'd reckon making it work is the first priority - efficiency can come
> > later.
> >
> I had an interesting experience with a bank once: they were not happy
> with the performance
> of XML when validating (because it slowed things down enough that they
> could not do their
> system integrity trials, which included both validation and load
> testing at the same time), but
> when I suggested caching the DTD, they seemed to think this would be a
> bit too much
> fiddling. In their case, if it wasn't efficient, it didn't work.
>
> So there is certainly a class of developers who, perhaps for good
> reasons of experience,
> expect that the difference between the out-of-the-box performance of a
> technology
> and the optimized performance should only be O(n) linear. I.e. that
> optimization
> is tweaking, not rewriting. Or, perhaps, that all optimizations are
> available through
> GUI switches or command-line arguments (or factory methods, or
> properties),
> not hacking by code.
>
> So --though I generally agree (who would gainsay Knuth et al.?) with
> Rick-- yet we cannot treat
> performance as a side-issue, or people with critical needs for high
> performance as speed-obsessed
> spoilers of the XML fun.
>
> Cheers
> Rick Jelliffe
|
