W3C home > Mailing lists > Public > public-xml-binary@w3.org > November 2004

Re: [xml-dev] binary XML API and scientific use cases [Re: [xml-dev] [ANN] nux-1.0beta2 release

From: Wolfgang Hoschek <whoschek@lbl.gov>
Date: Mon, 22 Nov 2004 16:39:18 -0800
Message-Id: <1BE7A53C-3CE8-11D9-B6EA-000A95BD16CE@lbl.gov>
Cc: public-xml-binary@w3.org, xml-dev@lists.xml.org
To: Aleksander Slominski <aslom@cs.indiana.edu>

>>>
>>> the natural question is: how does it compare to XBIS?
>>
>>
>> Among other things, we also benchmarked with the test xml files that 
>> come with XBIS (thanks to Dennis Sonoski for the great work - much 
>> appreciated). It would be interesting to directly compare performance 
>> with XBIS, but so far we did not do so, for two reasons:
>>
>> - XBIS currently does not work with XOM (misses some XMLReader 
>> features/properties that XOM requires)
>> - XBIS measures performance from and to SAX event streams. bnux 
>> measure performance from XOM documents to byte arrays, and back. bnux 
>> includes XOM tree walking, tree building, and the inherent XOM XML 
>> wellformedness checks, which is signifcantly more epensive (and also 
>> more useful, since it measure delivering data from/to a large number 
>> of real-world applications, rather than low-level SAX apps). In other 
>> words, the benchmarking methodology is different. It would not be an 
>> apples to apples comparison.
>
> so in other words XBIS is really streaming and is good for kind of 
> applications that do not need XOM (or *OM*-like) APIs.
>
>> Might still be interesting, though.
>
> XBIS could potentially process unlimited amount of data so nux could 
> not really compare.
>

Bnux is ideal for large volumes of small to medium-sized XML documents, 
  and impractical for individual documents that do not fit into main 
memory. So it's expressly not intended to deal with documents that do 
not fit into memory. It's not a use case we care much about.

In my experience, *very* large documents are more often than not a 
result of simplistic application design, and can easily be broken up 
into smaller documents with little effort on the part of the 
application programmer.

Finally, pipelining does not necessarily equal performance. In fact it 
can be the other way round, depending on the use cases at hand...

>
>>
>>>
>>>
>>> did you compare BNUX and XBIS performance?
>>
>>
>> see above.
>
> that is different. i had impression that BNUX defines binary XML 
> representation.
>
> i was curious how different is BNUX from XBIS.
>
> why did you decide not to use XBIS XML encoding?
>
> what is missing or needs to be added?
>
> those may be valuable insight for W3C XBC WG?


The bnux data format and algorithms are completely different than XBIS, 
except that they obviously attempt to address similar problem 
statements. Bnux's batch nature, it's tokenization and packing, its 
approach to character encoding and its simplicity are key to the 
performance results (as well as careful implementation, of course).

Wolfgang.
Received on Tuesday, 23 November 2004 04:05:04 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 1 December 2005 00:07:42 GMT