Dennis Sosnoski wrote:
Paul Sandoz wrote:
Manohar Naidu Ellanti wrote:
Paul,
thank you for pointing to XBIS and providing performance results.
I am surprised at the performance of (Fast Schema, X.694) compared to
FastInfoSet - I thought run-time conversion from ASN.1 to XML and
vice versa
using X.694 is more processor intensive than FastInfoSet - a blind
conversion from XML to ASN.1 and vice versa.
For (Fast Schema, X.694) there is no conversion from PER to XML it
goes straight from PER to Java objects and skips the infoset layer.
This is why you can get a 10x increase for certain schema and documents.
I personally find the Fast Web Services results from Sun less than
convincing, since they bypass the entire frameworks in order to get this
performance improvement. I suspect I could match these results using a
combination of my JiBX data binding framework with XBIS while still
preserving full XML compatibility over the wire (in other words, you'd
be able to just use an XBIS adapter to view the data transfers as XML
text documents - or to convert to full XML documents for passing on to
other stages of processing).
My experience of plugging in binary infoset encoders into JAXB (with
recent performance improvements) and JAX-RPC 1.X is contrary to what you
suspect. But i do not know much about JiBX...
If (Fast Schema, X.694) was used to go from PER to XML then
element/attribute/prefix/namespaces would all be hardcoded (and String
interned automatically in Java, which is good for binding applications
like JAXB which require this and Xerces by default interns) but
content will not be indexed (as is the case for Fast Infoset). In
addition the conversion of PER encoded values of integers etc to
characters will affect performance if a suitable API is not available
to access content as values other than characters.
The effects of this on performance should be minor in a well designed
framework.
I have found that string interning can be quite expensive. Some SAX
based applications require that the
http://xml.org/sax/features/string-interning; feature is true so that
'==' can be used instead of 'String.equals'.
Conversion of values to and from the lexical string representations can
also be expensive. See Expway's results [1] for Java with their SAX API
and their Base API (which allows access to values).
I'm not sure that FastInfoSet fits the bill, judging from
what I've heard about it second-hand. Manohar mentioned you'd provided
some performance comparisons with XBIS - I'd love to get a look at
these, if possible.
I've also been interested in running my own
benchmarks with a FastInfoSet encoder/decoder, but haven't been able to
find any available for testing. Can you supply any information on this?
Fast Infoset has properties very similar to XBIS. We expect that results
of the two (processing and size) will be comparable.
I implemented a prototype based on earlier ideas of Fast Infoset and
have performed some testing using the XBIS framework, :-), and another
framework SAX-based framework [2]. The prototype is not optimal as it
can be and will be modified according the an update of the Fast Infoset
specification.
Unfortunately i cannot be more open at the moment :-( I am looking at
possibilities for publishing some results of the prototype. I cannot
give anyone external access to the source.
Paul.
[1] http://www.expway.com/pdf/EXP-Benchmark-V2.0_Broadcast.pdf
[2] http://java.sun.com/performance/reference/whitepapers/XML_Test-1_0.pdf
http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22PartDetailId=xmltest-1_0-win-JPRSiteId=JSCTransactionId=noreg
--
| ? + ? = To question
\
Paul Sandoz
x19219
+353-1-8199219
