Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


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

From: Rick Marshall <rjm@-------.--->
To: Elliotte Harold <elharo@-------.---.--->
Date: 3/2/2007 9:57:00 PM
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.
>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent