Paul Sandoz wrote:
Manohar Naidu Ellanti wrote: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).
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.
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...
The effects of this on performance should be minor in a well designed framework.
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.
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=22&PartDetailId=xmltest-1_0-win-JPR&SiteId=JSC&TransactionId=noreg
-- | ? + ? = To question ----------------\ Paul Sandoz x19219 +353-1-8199219
