Thanks a lot for very detailled explanation. I am aware such benchmark can be tweaked to demonstrate whatever you like. I saw such a bench demonstrate JPA to be ugly slow compared to JDBC - just lauching 10 request, forgotting the EntityManager startup time ;)
The Jaxb vs XStream is the most interesting case, but as you said it can't be consider a "drop as replacement" until some specific dev is done - if even possible. I'll take a look at sxc that seems a far better solution, it remains me Jibx that I used some time ago with good results. Best regards, have a nice week-end Nicolas 2009/4/24 Daniel Kulp <[email protected]> > 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 >
