Re: [xml-dev] Speed in Languages and Browser Architectures

[Rick Marshall <rjm@zenucom.com>]

String processing in C is tricky at best. Why? well there's no such 
thing as a string in C...

So Dennis decided a string was an ascii sequence of bytes terminated by 
a 'NUL' (and not containing a NUL). This has lots of limitations and 
over the years the definition and libraries have changed - but string is 
a library, not a language concept.

Then to confound the issue most modern C compilers take advantage of 
native string processing instructions in modern CPUs so many elements of 
the standard C string library are actually compiled into single CPU 
instructions (yeah I know the microcode does lots of instructions).

So performance of C and strings is notoriously difficult to measure 
accurately and can vary wildly between architectures, libraries, and 
compilers.

I expect Java and C# are much more consistent.

Guess it's time to write some code my way and see what happens

Rick

Elliotte Harold wrote:
> derek denny-brown wrote:
>
>> Except that we are talking about the performance of XML parsers, and
>> XML is all about string processing and Java string processing is slow.
>> Java XML parsing will never be faster than a good XML parser written
>> in C.  There is just too much overhead, and C benefits from 'struct's,
>> the lack of which hinders ones ability to write certain constructs
>> efficiently in Java.   
>
> My god! Are we moving back on topic? Has this ever happened before? `-)
>
> Even if your assertions about string processing are true, there's no 
> rule that says you have to use strings to write an XML processor. Off 
> the top of my head I can think of three XML libraries/APIs for Java 
> that deliberately avoid java.lang.String for some of their work.
>
> If performance were really a concern, and String proved to be the real 
> bottleneck, it's entirely possible someone could write an XML API 
> based on bytes rather than strings. So far I don't think anyone's 
> really had the motivation to do so. Either it hasn't been shown that 
> strings are the problem, or they're not a big enough problem that 
> anyone wants to take the time to fix them.
>