On Fri April 24 2009 11:39:48 am nicolas de loof wrote:
> Hi
> I just found this blog
> http://salomo-petrus.blogspot.com/2009/02/fastest-xml-parser.html
> about XML parser comparison
>
> Benchs are only benchs, so this may not be significant, but I'm afraid
> about JAXB perfs in result.

The only way JAXB would be that slow compared to the others is if he's 
creating a new JAXBContext for each call, which would be nuts and isn't 
something we do.     The other issue is:

>25 threads running simultaniously
>Every thread calls the parser 100 times

So 2500 requests.     The client VM won't even begin to JIT anything until the 
1000th time in.  (server VM is 10000)  Thus, in this case, the JIT starts 
consuming resources about 1/3 of the way through.   JAXB, due to it's size and 
complexity and a LOT of methods causes a HUGE pause as the JIT kicks in, but 
once the jit has done it's work, it flies.    Also, not sure "which" JAXB 2.1 
he used. JAXB 2.1.(x > 6) has some optimized direct access stuff to the 
primitives which makes it a TON faster.    Also, did he call unmarshal with 
the XmlSreamReader, XmlEventReader, InputStream, DOM, etc....?    Likewise, 
when benchmarking xstream, did they use stax streams or raw input streams?

Comparing to Piccolo and StaxMate is almost silly.  Neither actually build up 
anything.  Both are really just the XML parsers parts equivilent to an 
XmlStreamReader or similar.   Both would require something else (like jaxb) to 
build up the useful javamodel.   JDom is similar in that it only builds up a 
"dom", not a useful typed object model.  

Thus, that does leave XStream vs JAXB.  See above.  :-)    XStream seems to be 
pretty close to Aegis.   Kind of wonder how they would compare.

Anyway, without the benchmark code, I really don't think much can be derived 
from those numbers.    (oh, and with something like CXF, marshalling 
performance is also important)

> My webservices are generated using cxf-maven plugin from WSDL, so use JAXB
> for binding. Is there any way to switch (if necessary) to another parser
> strategy without (structural) changes in generated classes ?

Probably not easy depending on how easy the jaxb classes can be converted to 
xstream classes.

It looks like xstream supports reading/writing from/to the standard Stax 
streams.   Thus, it would be relatively easy to write a databinding for CXF 
for it.   (the obj -> wsdl/xsd stuff might be tricky.  Not sure if they have 
anything for that yet.  Haven't dug in there.)    If someone wanted to tackle 
that, that would be a great project.   :-)

Finally, if you want better performance from JAXB, try sxc (sxc.codehaus.org).  
 
It doesn't fully support JAXB yet, but if the schemas you have meet it's 
restrictions, it can be a huge help.

-- 
Daniel Kulp
[email protected]
http://www.dankulp.com/blog

Reply via email to