[jason.greene]

Right, the binding is really what I was thinking would be the actual area to improve on. You are definitely correct that with only 30% of the time being binding we may be disappointed. However, I suspect that the parsing time portion of the pie is off because of schema validation. That is known to be slow. We should try disabling that and see what we get.

I should use more precise terminology. I mean binding generation.

[adrian.brock]

Adrian, I'd have to disagree as the number of JbossXB classes will probably be very similar to the number of JAXB annotated classes that AS will use.

Which actually argues against it being the classloading making a difference in this test. ;-)

$ jar -tf jboss-xml-binding.jar | wc -l
351

So your argument is reversed once there are more than ~350 classes in all the object models that need to be parsed, e.g.

$ jar -tf jboss-metadata.jar | wc -l
812

[bill.burke]

Hey, classloading was the only thing I could think of. You said earlier that after the first 100 iterations fast-jaxb was faster, right?

[adrian.brock]

Hey, classloading was the only thing I could think of. You said earlier that after the first 100 iterations fast-jaxb was faster, right?

Yes, once its warmed up, it looks like ~30% faster for Alex's simple test.

[aloubyansky]

Yes, performance comparison depends on specific test, since binding logic (at least the current one) depends on the number of properties, etc. So, if there are lots of classes with lots properties the outcome for the comparison may be quite different.

Also having fast start-up time as the goal (e.g. my container starts in 2 sec), parsing has to be fast and optimized for the first run. There is no time to warm up.

Besides that, another thing that worries me and which has been missing attention is marshalling. With the rapid development of all the advanced unmarshalling features marshalling has been totally lost. And if we are revisiting our binding needs I think it makes sense to keep marshalling in mind. Otherwise, we might be trapped.

[bill.burke]

Because of marshalling, I don't understand why we can't use Sun's JAXB? WHy spend another year getting marshalling right? What *REAL* benefits will be obtained?

Also, again, please try your benches against XJC generated Java code. I'd be interested how it compares.

[jesper.pedersen]

I changed my XML parsing from JAXB/XJC to a StAX model (Sun implementation). Maybe Woodstock can lower the times even more...

JAXB/XJC:
bootstrap.xml: 385 ms
naming.xml: 71 ms
transaction.xml: 23 ms
jca.xml: 58 ms

StAX:
bootstrap.xml: 18 ms
naming.xml: 5 ms
transaction.xml: 1 ms
jca.xml: 2 ms

The times are from the file handle is created to the Java model is returned, e.g. includes the time spend on creating factories and unmarshallers.

There may be other areas that needs to be covered by JBXB - so I can't say if the results will map directly to your case.

[aloubyansky]

Because of marshalling, I don't understand why we can't use Sun's JAXB? WHy spend another year getting marshalling right? What *REAL* benefits will be obtained?

Good if we can. But for currrent metadata we can't since it's using to many JBXB-specific features and annotations.