Re: [Axis2] Binary Serialisation

[Dan Diephouse <da...@envoisolutions.com>]

Has anyone done any performance tests (binary or just plan text) with 
the typed stax stuff? Does it really make a difference?
- Dan

Eran Chinthaka wrote:

>Hi Dennis,
>
>You have commented on typed pull parser in wiki. Shall we start a thread
>about it here ?
>
>-- EC
>
>  
>
>>-----Original Message-----
>>From: Apache Wiki [mailto:wikidiffs@apache.org]
>>Sent: Thursday, July 28, 2005 10:31 PM
>>To: general@ws.apache.org
>>Subject: [Ws Wiki] Update of "FrontPage/Axis2/Tasks/BinarySerialization"
>>by DennisSosnoski
>>
>>Dear Wiki user,
>>
>>You have subscribed to a wiki page or wiki category on "Ws Wiki" for
>>change notification.
>>
>>The following page has been changed by DennisSosnoski:
>>http://wiki.apache.org/ws/FrontPage/Axis2/Tasks/BinarySerialization
>>
>>--------------------------------------------------------------------------
>>----
>>  decoding the binary into an int, converting to a string for the parser
>>  API and then back to an int in the deserialisation code.
>>
>>+ I (DennisSosnoski) would personally disagree with the above assessment.
>>A typed pull parser would definitely be nice, but even without this you
>>can get substantial size and performance gains from a binary format. See
>>my articles on devWorks at http://www-
>>128.ibm.com/developerworks/xml/library/x-trans1.html and http://www-
>>128.ibm.com/developerworks/xml/library/x-trans2/index.html for examples.
>>+
>>    
>>
>
>
>
>  
>


-- 
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com

Re: [Axis2] Binary Serialisation

[Tatu Saloranta <co...@yahoo.com>]

--- Dennis Sosnoski <dm...@sosnoski.com> wrote:

> Tatu Saloranta wrote:
> 
> >...
> >I don't see the need to call 3 accessor methods to
> get
> >the raw char array as a significant performance
> block
>
> I didn't mean to suggest that the 3 method calls
> caused a performance 
> problem - it's just somewhat awkward, and giving
> access to the 
> underlying parser buffer is not very clean from a
> structure standpoint. 

Ah, yes, I agree with that.

> The big potential advantage I see with a
> CharSequence-type approach is 
> that it would allow the parser to avoid translating
> data to a char[] in 
> the first place, instead returning characters
> directly from the byte 
> stream input (or internal byte[]). For UTF-8 and
> UTF-16 this would be 
> very easy to implement - it's not so easy for some
> other character 
> encodings, but those could be handled by the current
> approach of 
> translating everything to chars up front.

For UTF-16 it's easier, but for UTF-8... I'm not quite
sure. Or rather, that it would still lead to the need
to scan same data at least twice (unless it's just
passed through as is); first when tokenizing (which
can be done without char conversion), and then when
some form of character data is needed?

What would be interesting to know, too, would be
whether CharacterSequence usage might be a performance
overhead too, it being an interface. I know that
HotSpot can not always (or even often) optimize calls
via interfaces as efficiently as via (final?) classes.
For example, I tested access both using HashMap
reference, and a generic Map reference that points to
a HashMap (with JDK 1.4.2), and latter was
significantly slower (yes, just a micro-benchmark...
but I think it's applicable). This because
String.charAt() I think can nowadays be as fast as
cbuf[i] (claims JavaSoft).

Lots of open questions, obviously. From API cleanness
viewpoint I do like CharacterSequence idea though.

...
> It'd be interesting to see how much parsing speeds
> up if you disable the 
> creation of Strings for attributes. Maybe that's an
> easy test you could try?

Yes, it's actually something I was thinking of adding
to "StAX2" API, and should be easy to implement.
Current implementation is actually somewhat optimized,
at least for elements that have multiple attributes:
under the hood, one long String is created (first time
a value is needed), and substrings of that one built
String are returned (except for a single value, in
which case it's returned as is). This is an
opportunistic optimization that I probably should 
benchmark bit more.

But perhaps I should see how attribute access
performance is -- most testing I have done has been
based on just raw parsing, not attribute access.

In case of StAX, anyways, attribute values are (or
should be...) generally lazily constructed, when
needed.

> As to typed accessors, I think they'd be somewhat
> useful but I expect 
> they'd also be a lot of trouble. The main benefit I

Yes, depending on where they are implemented. The most
efficient (and trickiest) would be to couple them with
tokenization... but that'd be a mess, both due to
added code at low-level, but also since it means that
there needs to be a priori knowledge of types.

On the other hand, simpler solution would be to
essentially wrap raw char array (or CharSequence) and
do conversion from there, by-passing String
construction. This need not even be in parser proper.

> see is that they 
> would make it simpler to substitute a binary data
> decoder for the 
> parser, and I'm not all that thrilled by the idea of
> pure binary data 
> streams. The binary formats would be based on
> schemas, so in theory 
> different implementations should translate the same
> schema to compatible 
> formats - but we can't even get a reasonable level
> of compatibility in 
> the use of schemas for web services with *text*
> documents, so how much 
> more difficult would it be to do this with binary
> formats?

I definitely agree with these concerns.

And in the end, I'm not 100% sure if all performance
concerns are valid. Last time I tested, almost half
(40%) of time when parsing xml docs was for raw i/o,
so overhead is "only" about half of the total
interaction time. While not perfect, I think many
people assume there'd be an order of magnitude
discrepancy or so.

And in case of binary indexing; the proposal was to
force storing the whole document in memory all at
once. That may well offset some benefits of the
approach; since although it does allow more
pass-through (raw copy) approach, for things like
routing, it also increases memory usage; index offsets
need to be recalculated when things are changed, and
in the end it may well be that speedup is somewhere in
range of 10 - 25% (as in not phenomenal).

-+ Tatu +-



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [Axis2] Binary Serialisation

[Dennis Sosnoski <dm...@sosnoski.com>]

Tatu Saloranta wrote:

>...
>I don't see the need to call 3 accessor methods to get
>the raw char array as a significant performance block
>-- it certainly does not even register on profiles I
>have taken for parsing.
>  
>
I didn't mean to suggest that the 3 method calls caused a performance 
problem - it's just somewhat awkward, and giving access to the 
underlying parser buffer is not very clean from a structure standpoint. 
The big potential advantage I see with a CharSequence-type approach is 
that it would allow the parser to avoid translating data to a char[] in 
the first place, instead returning characters directly from the byte 
stream input (or internal byte[]). For UTF-8 and UTF-16 this would be 
very easy to implement - it's not so easy for some other character 
encodings, but those could be handled by the current approach of 
translating everything to chars up front.

>The only remaining area where non-shared Strings are
>used are attribute values; and here DTD/schema-based
>handling might allow sharing too (for enumerated
>types). Or, for minor improvements, type-based
>accessors could be used too. If there's interest, I
>could experiment with Woodstox stax-parser -- adding
>low-level typed accessors would be quite easy to do,
>and would avoid String creation.
>  
>
It'd be interesting to see how much parsing speeds up if you disable the 
creation of Strings for attributes. Maybe that's an easy test you could try?

As to typed accessors, I think they'd be somewhat useful but I expect 
they'd also be a lot of trouble. The main benefit I see is that they 
would make it simpler to substitute a binary data decoder for the 
parser, and I'm not all that thrilled by the idea of pure binary data 
streams. The binary formats would be based on schemas, so in theory 
different implementations should translate the same schema to compatible 
formats - but we can't even get a reasonable level of compatibility in 
the use of schemas for web services with *text* documents, so how much 
more difficult would it be to do this with binary formats?

  - Dennis

Re: [Axis2] Binary Serialisation

[Tatu Saloranta <co...@yahoo.com>]

--- Dennis Sosnoski <dm...@sosnoski.com> wrote:

> That's a very nice approach for generating and
> persisting what amounts 
> to pre-parsed documents. If you were to transmit the
> token descriptor 
> data structures along with the XML document it'd
> pretty much eliminate 
> parsing for the receiver, but would apparently about
> double the document 
> size on average. The really nice use for this type
> of approach is as an 
> alternative to an object model composed of separate
> objects per 
> component, though.

True. However, I think they are overstating the degree
to which String objects (one of bigger performance
bottlenecks in parsing) are created, on temporary
basis. All modern XML parsers use fully shared Strings
for names (prefix, local name), and at least locally
shared for NS URIs. When done the right way, these can
also be shared between documents produced by parsers
that share the same string pool (or intern()).
With both SAX and StAX, one can easily access char[]
representation of textual content (with obviously
slightly more cumbersome processing as compared to
Strings -- CharacterSequence might solve, or might not
solve, problem being mutability of the underlying char
array).
I don't see the need to call 3 accessor methods to get
the raw char array as a significant performance block
-- it certainly does not even register on profiles I
have taken for parsing.

The only remaining area where non-shared Strings are
used are attribute values; and here DTD/schema-based
handling might allow sharing too (for enumerated
types). Or, for minor improvements, type-based
accessors could be used too. If there's interest, I
could experiment with Woodstox stax-parser -- adding
low-level typed accessors would be quite easy to do,
and would avoid String creation.

> Unfortunately it doesn't fit very well with either a
> StAX or DOM-like 
> API, because those use Strings (almost) everywhere.
> It'd work much 
> better in combination with a CharSequence-based API.

I haven't fully read the proposal, but it might be
possible to make use of such annotation, as long as
the parser can keep byte-accurate offsets during
parsing. This is one problem I have not yet solved,
since it does require merging of the byte->char
conversion and tokenization parts; something that
makes design less clean (and adds code size, since
generic decoders can not be used), albeit potentially
more performant (single scan instead of double scan).

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Axis2] Binary Serialisation

[Dennis Sosnoski <dm...@sosnoski.com>]

That's a very nice approach for generating and persisting what amounts 
to pre-parsed documents. If you were to transmit the token descriptor 
data structures along with the XML document it'd pretty much eliminate 
parsing for the receiver, but would apparently about double the document 
size on average. The really nice use for this type of approach is as an 
alternative to an object model composed of separate objects per 
component, though.

Unfortunately it doesn't fit very well with either a StAX or DOM-like 
API, because those use Strings (almost) everywhere. It'd work much 
better in combination with a CharSequence-based API.

  - Dennis

Anne Thomas Manes wrote:

>This project seems to provide substantial performance advantages in
>XML processing. Take a look at the benchmark paper:
>http://www.ximpleware.com/.
>
>Anne
>

Re: [Axis2] Binary Serialisation

[Anne Thomas Manes <at...@gmail.com>]

This project seems to provide substantial performance advantages in
XML processing. Take a look at the benchmark paper:
http://www.ximpleware.com/.

Anne

On 7/29/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Looks like we've got a thread going, Eran!
> 
> Dan, I don't think anyone has done a performance analysis for a typed
> parser as such. It'd really need to be done in the context of some sort
> of data binding framework to be meaningful. The only thing which has
> been done along these lines that I'm aware of is Sun's "FAST Web
> Services", which merged mutant forms of JAXB and JAX-RPC so that they
> could do binary input/output. In their case they used ASN.1
> encoding/decoding of the binary data, with the ASN.1 representation
> generated from an XML Schema.
> 
> They saw much faster performance than the conventional JAX-RPC code.
> But, my own JibxSoap (a subproject of JiBX, http://www.jibx.org)
> delivers performance that appears to be about as good while still using
> standard text XML. I say "appears to be" because at the time I did the
> web services performance comparisons
> (http://www.sosnoski.com/presents/cleansoap/comparing.html) the Sun
> stuff was all proprietary. They've since opened it up on java.net, I
> think, though I don't know what kind of license restrictions might apply.
> 
> My own gut feeling is that if I used a typed parser interface for binary
> input/output with JiBX/JibxSoap I could probably get 2-2.5 X the
> processing speed of text (vs. probably about 1.4-1.8 X with my XBIS
> binary XML format, which still keeps values as text and can be
> translated to and from the text representation).
> 
> There are actually some other areas where parser usability could be
> improved, though, besides implementing a typed interface. I think
> implementing a parser that supplied element and attribute names as
> singleton QName objects of some form (rather than separate namespace
> URI, local name, and qualified name text values) would be a big gain,
> for instance. The text APIs could also be better designed; in the case
> of the StAX XMLReader, rather than returning an array plus start offset
> plus length for element content, all using separate method calls, it'd
> be cleaner to just return the equivalent of a JDK 1.5 CharSequence
> (which could be reusable). Likewise on the attribute values, where StAX
> returns Strings. Returning CharSequence-equivalents would not only avoid
> unnecessary String creation (in the case of attribute values), it would
> also eliminate the need to translate the raw byte stream to character
> arrays for common encodings (especially the UTF-8 and UTF-16 used in
> BP-compliant web services).
> 
> Unfortunately, I think developers sometimes misapply Knuth's (or Hoare's
> - I'm not sure who got this started) "premature optimization is the root
> of all evil" aphorism by designing APIs without any thought to
> performance. Once performance bottlenecks have been built into the APIs
> it's very difficult to get around them without scrapping things and
> starting over.
> 
>   - Dennis
> 
> Dan Diephouse wrote:
> 
> > Has anyone done any performance tests (binary or just plan text) with
> > the typed stax stuff? Does it really make a difference?
> > - Dan
> >
> > Eran Chinthaka wrote:
> >
> >> Hi Dennis,
> >>
> >> You have commented on typed pull parser in wiki. Shall we start a thread
> >> about it here ?
> >>
> >> -- EC
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Apache Wiki [mailto:wikidiffs@apache.org]
> >>> Sent: Thursday, July 28, 2005 10:31 PM
> >>> To: general@ws.apache.org
> >>> Subject: [Ws Wiki] Update of
> >>> "FrontPage/Axis2/Tasks/BinarySerialization"
> >>> by DennisSosnoski
> >>>
> >>> Dear Wiki user,
> >>>
> >>> You have subscribed to a wiki page or wiki category on "Ws Wiki" for
> >>> change notification.
> >>>
> >>> The following page has been changed by DennisSosnoski:
> >>> http://wiki.apache.org/ws/FrontPage/Axis2/Tasks/BinarySerialization
> >>>
> >>> --------------------------------------------------------------------------
> >>>
> >>> ----
> >>>  decoding the binary into an int, converting to a string for the parser
> >>>  API and then back to an int in the deserialisation code.
> >>>
> >>> + I (DennisSosnoski) would personally disagree with the above
> >>> assessment.
> >>> A typed pull parser would definitely be nice, but even without this you
> >>> can get substantial size and performance gains from a binary format.
> >>> See
> >>> my articles on devWorks at http://www-
> >>> 128.ibm.com/developerworks/xml/library/x-trans1.html and http://www-
> >>> 128.ibm.com/developerworks/xml/library/x-trans2/index.html for
> >>> examples.
> >>> +
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>

Re: [Axis2] Binary Serialisation

[Dan Diephouse <da...@envoisolutions.com>]

Eran Chinthaka wrote:

>Hi XML Gurus, 
>
>Can I ask a novice question about Binary XML stuff ??. 
>
>Is there any existing implementations of binary protocols with StAX support
>? In other words are there any implementations which provides StAX events on
>a binary stream.
>Once I can remember Mark Pimentel mentioned something like that (Was it Fast
>Infoset ??). 
>
>If there is one, can we integrate that to Axis2 and see how much performance
>improvement we can gain out of it. I'd love to integrate at least one of the
>existing implementations, before Mark finishes his project.
>
>-- Eran Chinthaka 
>  
>
Fast Infoset Project: https://fi.dev.java.net/

Never tried it though. Have others?

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com

RE: [Axis2] Binary Serialisation

[Eran Chinthaka <ch...@opensource.lk>]

Hi XML Gurus, 

Can I ask a novice question about Binary XML stuff ??. 

Is there any existing implementations of binary protocols with StAX support
? In other words are there any implementations which provides StAX events on
a binary stream.
Once I can remember Mark Pimentel mentioned something like that (Was it Fast
Infoset ??). 

If there is one, can we integrate that to Axis2 and see how much performance
improvement we can gain out of it. I'd love to integrate at least one of the
existing implementations, before Mark finishes his project.

-- Eran Chinthaka 

> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Friday, July 29, 2005 10:56 AM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] Binary Serialisation
> 
> Looks like we've got a thread going, Eran!
> 
> Dan, I don't think anyone has done a performance analysis for a typed
> parser as such. It'd really need to be done in the context of some sort
> of data binding framework to be meaningful. The only thing which has
> been done along these lines that I'm aware of is Sun's "FAST Web
> Services", which merged mutant forms of JAXB and JAX-RPC so that they
> could do binary input/output. In their case they used ASN.1
> encoding/decoding of the binary data, with the ASN.1 representation
> generated from an XML Schema.
> 
> They saw much faster performance than the conventional JAX-RPC code.
> But, my own JibxSoap (a subproject of JiBX, http://www.jibx.org)
> delivers performance that appears to be about as good while still using
> standard text XML. I say "appears to be" because at the time I did the
> web services performance comparisons
> (http://www.sosnoski.com/presents/cleansoap/comparing.html) the Sun
> stuff was all proprietary. They've since opened it up on java.net, I
> think, though I don't know what kind of license restrictions might apply.
> 
> My own gut feeling is that if I used a typed parser interface for binary
> input/output with JiBX/JibxSoap I could probably get 2-2.5 X the
> processing speed of text (vs. probably about 1.4-1.8 X with my XBIS
> binary XML format, which still keeps values as text and can be
> translated to and from the text representation).
> 
> There are actually some other areas where parser usability could be
> improved, though, besides implementing a typed interface. I think
> implementing a parser that supplied element and attribute names as
> singleton QName objects of some form (rather than separate namespace
> URI, local name, and qualified name text values) would be a big gain,
> for instance. The text APIs could also be better designed; in the case
> of the StAX XMLReader, rather than returning an array plus start offset
> plus length for element content, all using separate method calls, it'd
> be cleaner to just return the equivalent of a JDK 1.5 CharSequence
> (which could be reusable). Likewise on the attribute values, where StAX
> returns Strings. Returning CharSequence-equivalents would not only avoid
> unnecessary String creation (in the case of attribute values), it would
> also eliminate the need to translate the raw byte stream to character
> arrays for common encodings (especially the UTF-8 and UTF-16 used in
> BP-compliant web services).
> 
> Unfortunately, I think developers sometimes misapply Knuth's (or Hoare's
> - I'm not sure who got this started) "premature optimization is the root
> of all evil" aphorism by designing APIs without any thought to
> performance. Once performance bottlenecks have been built into the APIs
> it's very difficult to get around them without scrapping things and
> starting over.
> 
>   - Dennis
> 
> Dan Diephouse wrote:
> 
> > Has anyone done any performance tests (binary or just plan text) with
> > the typed stax stuff? Does it really make a difference?
> > - Dan
> >
> > Eran Chinthaka wrote:
> >
> >> Hi Dennis,
> >>
> >> You have commented on typed pull parser in wiki. Shall we start a
> thread
> >> about it here ?
> >>
> >> -- EC
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Apache Wiki [mailto:wikidiffs@apache.org]
> >>> Sent: Thursday, July 28, 2005 10:31 PM
> >>> To: general@ws.apache.org
> >>> Subject: [Ws Wiki] Update of
> >>> "FrontPage/Axis2/Tasks/BinarySerialization"
> >>> by DennisSosnoski
> >>>
> >>> Dear Wiki user,
> >>>
> >>> You have subscribed to a wiki page or wiki category on "Ws Wiki" for
> >>> change notification.
> >>>
> >>> The following page has been changed by DennisSosnoski:
> >>> http://wiki.apache.org/ws/FrontPage/Axis2/Tasks/BinarySerialization
> >>>
> >>> ----------------------------------------------------------------------
> ----
> >>>
> >>> ----
> >>>  decoding the binary into an int, converting to a string for the
> parser
> >>>  API and then back to an int in the deserialisation code.
> >>>
> >>> + I (DennisSosnoski) would personally disagree with the above
> >>> assessment.
> >>> A typed pull parser would definitely be nice, but even without this
> you
> >>> can get substantial size and performance gains from a binary format.
> >>> See
> >>> my articles on devWorks at http://www-
> >>> 128.ibm.com/developerworks/xml/library/x-trans1.html and http://www-
> >>> 128.ibm.com/developerworks/xml/library/x-trans2/index.html for
> >>> examples.
> >>> +
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >

Re: [Axis2] Binary Serialisation

[Dennis Sosnoski <dm...@sosnoski.com>]

Looks like we've got a thread going, Eran!

Dan, I don't think anyone has done a performance analysis for a typed 
parser as such. It'd really need to be done in the context of some sort 
of data binding framework to be meaningful. The only thing which has 
been done along these lines that I'm aware of is Sun's "FAST Web 
Services", which merged mutant forms of JAXB and JAX-RPC so that they 
could do binary input/output. In their case they used ASN.1 
encoding/decoding of the binary data, with the ASN.1 representation 
generated from an XML Schema.

They saw much faster performance than the conventional JAX-RPC code. 
But, my own JibxSoap (a subproject of JiBX, http://www.jibx.org) 
delivers performance that appears to be about as good while still using 
standard text XML. I say "appears to be" because at the time I did the 
web services performance comparisons 
(http://www.sosnoski.com/presents/cleansoap/comparing.html) the Sun 
stuff was all proprietary. They've since opened it up on java.net, I 
think, though I don't know what kind of license restrictions might apply.

My own gut feeling is that if I used a typed parser interface for binary 
input/output with JiBX/JibxSoap I could probably get 2-2.5 X the 
processing speed of text (vs. probably about 1.4-1.8 X with my XBIS 
binary XML format, which still keeps values as text and can be 
translated to and from the text representation).

There are actually some other areas where parser usability could be 
improved, though, besides implementing a typed interface. I think 
implementing a parser that supplied element and attribute names as 
singleton QName objects of some form (rather than separate namespace 
URI, local name, and qualified name text values) would be a big gain, 
for instance. The text APIs could also be better designed; in the case 
of the StAX XMLReader, rather than returning an array plus start offset 
plus length for element content, all using separate method calls, it'd 
be cleaner to just return the equivalent of a JDK 1.5 CharSequence 
(which could be reusable). Likewise on the attribute values, where StAX 
returns Strings. Returning CharSequence-equivalents would not only avoid 
unnecessary String creation (in the case of attribute values), it would 
also eliminate the need to translate the raw byte stream to character 
arrays for common encodings (especially the UTF-8 and UTF-16 used in 
BP-compliant web services).

Unfortunately, I think developers sometimes misapply Knuth's (or Hoare's 
- I'm not sure who got this started) "premature optimization is the root 
of all evil" aphorism by designing APIs without any thought to 
performance. Once performance bottlenecks have been built into the APIs 
it's very difficult to get around them without scrapping things and 
starting over.

  - Dennis

Dan Diephouse wrote:

> Has anyone done any performance tests (binary or just plan text) with 
> the typed stax stuff? Does it really make a difference?
> - Dan
>
> Eran Chinthaka wrote:
>
>> Hi Dennis,
>>
>> You have commented on typed pull parser in wiki. Shall we start a thread
>> about it here ?
>>
>> -- EC
>>
>>  
>>
>>> -----Original Message-----
>>> From: Apache Wiki [mailto:wikidiffs@apache.org]
>>> Sent: Thursday, July 28, 2005 10:31 PM
>>> To: general@ws.apache.org
>>> Subject: [Ws Wiki] Update of 
>>> "FrontPage/Axis2/Tasks/BinarySerialization"
>>> by DennisSosnoski
>>>
>>> Dear Wiki user,
>>>
>>> You have subscribed to a wiki page or wiki category on "Ws Wiki" for
>>> change notification.
>>>
>>> The following page has been changed by DennisSosnoski:
>>> http://wiki.apache.org/ws/FrontPage/Axis2/Tasks/BinarySerialization
>>>
>>> -------------------------------------------------------------------------- 
>>>
>>> ----
>>>  decoding the binary into an int, converting to a string for the parser
>>>  API and then back to an int in the deserialisation code.
>>>
>>> + I (DennisSosnoski) would personally disagree with the above 
>>> assessment.
>>> A typed pull parser would definitely be nice, but even without this you
>>> can get substantial size and performance gains from a binary format. 
>>> See
>>> my articles on devWorks at http://www-
>>> 128.ibm.com/developerworks/xml/library/x-trans1.html and http://www-
>>> 128.ibm.com/developerworks/xml/library/x-trans2/index.html for 
>>> examples.
>>> +
>>>   
>>
>>
>>
>>
>>  
>>
>
>