Lists Home |
Date Index |
Wolfgang Hoschek wrote:
> A new performance oriented parser implementation must come with a
> straightforward API, or else it will matter little in practise.
Yes, but how will that help Rick M's problem?
"some initial investigation reveals that the vast majority of the time
is spent parsing the input strings and coping with utf-8."
See, what I think is happening is that instead of you saying "Yes SSE
optimization research would be good; and better APIs would be good; and
my expectations is that more good would come from better APIs" you seem
to be saying "NO AMOUNT of SSE optimization is needed because the
problem is APIs".
Similarly, instead of saying "Yes SSE optimization research would be
good; and better algorithms would be good; and my expectations is that
good would come from better algorithms" Rick M seems to be saying "NO
AMOUNT of SSE optimization is needed because the problem is algorithms".
I don't see any reason that progress in one area would limit progress in
others. However, the attitude of denying the need for improvements in
one area until some pet area is adequately addressed just serves to hold
back any improvement. Observers draw the wrong conclusion "they cannot
even agree on the central problem, lets not go ahead" rather than "oh,
there is potential on several fronts, lets go ahead!" IYSWIM
That is why, ultimately, the current XML efficiency problem is not with
technology: not APIs, algorithms, CPU instruction sets. The XML
efficiency problem is with motivating researchers and open source
developers into areas that match corporate business requirements.