Re: XML Performance in a Transacation
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. Cheers Rick Jelliffe
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format