-
15. Re: XB profiling during the AS start-up
"david.lloyd@jboss.com" wrote:
"alex.loubyansky@jboss.com" wrote:
"adrian" wrote:
fast jaxb is clearly faster at the binding
But binding was out of the scope of the test.
I'd say not, since we are doing it at runtime in AS now, and that may be one source of startup time issues.
I said the binding was out of the scope of THE test. The test didn't compare binding times. I didn't say it's irrelevant. -
16. Re: XB profiling during the AS start-up
"adrian@jboss.org" wrote:
"alex.loubyansky@jboss.com" wrote:
"adrian" wrote:
fast jaxb is clearly faster at the binding
But binding was out of the scope of the test.
I don't understand that? Surely the unmarshaller.parse() will bind the xml to the
objects in both tests?
Ah, we meant different things. By binding I meant building the SchemaBinding and other pre-parsing steps. -
17. Re: XB profiling during the AS start-up
"adrian@jboss.org" wrote:
"alex.loubyansky@jboss.com wrote:
"adrian" wrote:
If the code generation was moved to compile time (like xjc), then having
already generated classes will obviously out perform the reflection used by JBossXBBuilder.
Fast jaxb parsers had been generated and compiled before the test run.
Ok, so what is fast jaxb doing that it is 3 times slower on the first iteration
(even though you have already pre-generated classes)?
Is it parsing the xml schema or something? Are you comparing apples to apples?
I actually can't comment at the moment of what the bottleneck is. Maybe I'm missing something, but it looks to me like apples to apples.
At least that's how a simple parsing client is supposed to use the API. -
18. Re: XB profiling during the AS start-up
"alex.loubyansky@jboss.com" wrote:
"adrian@jboss.org" wrote:
jaxb parsers had been generated and compiled before the test run.
Ok, so what is fast jaxb doing that it is 3 times slower on the first iteration
(even though you have already pre-generated classes)?
Is it parsing the xml schema or something? Are you comparing apples to apples?
I actually can't comment at the moment of what the bottleneck is. Maybe I'm missing something, but it looks to me like apples to apples.
At least that's how a simple parsing client is supposed to use the API.
Perhaps it's something like Adrian suggests where the fast-jaxb classes are using schema validation. It just doesn't make sense that a pregenerated parser would be slower than a dynaimc reflection based model. The pregenerated version has less work to actually do, and it can do direct method invocation as opposed to reflection which is definitely faster. -
19. Re: XB profiling during the AS start-up
Another thing to check, is to make sure they are using the same parser. JBossxb could be bringing in a better version of xerces, while the fast-jaxb generated parser is using the jdk version.
-
20. Re: XB profiling during the AS start-up
Fast jaxb doesn't parse schema itself. It maybe the SAX parser behind the scene. But the same SAXParserFactory is used by XB. All the initialization is in the test. XB does enable validation and schema awareness. There must be something else.
-
21. Re: XB profiling during the AS start-up
All I know is that a code generation approach reduces bind time to zero as the only overhead is loading the parser classes. I am not an XML parsing expert. I just used the Sax parser that comes with the JDK. Also, the algorithm I used may not be optimal as fast-jaxb was the first time I ever wrote a sax parser.
-
22. Re: XB profiling during the AS start-up
Also, I think you should do some timing against XJC generated code.
-
23. Re: XB profiling during the AS start-up
"alex.loubyansky@jboss.com" wrote:
Fast jaxb doesn't parse schema itself. It maybe the SAX parser behind the scene. But the same SAXParserFactory is used by XB. All the initialization is in the test. XB does enable validation and schema awareness. There must be something else.
Yes this is what I was referring to. Making sure they have identical sax parsers and configuration.
One issue I just noticed is that the generated parser does a if/else switch style tree with equalsIgnoreCase(). JBossXB uses maps internally, so this could be one area of difference. -
24. Re: XB profiling during the AS start-up
BTW, there is no XSD at all in this test. So validation is not done.
Yes, I understand the impl based on generated parsers may not be the most optimal possible. This is not meant to criticize the idea in general.
I am puzzled by the results myself. -
25. Re: XB profiling during the AS start-up
"jason.greene@jboss.com" wrote:
and it can do direct method invocation as opposed to reflection which is definitely faster.
I think you'll find that that is probably not as relevant as you think.
This is a similar problem to Serialization.
The time it takes to
1) decide what to do - typically a string comparison on an element or attribute name
2) coerce xml data into non-string types
will likely "swamp" the small amount of extra time it takes to invoke a setter via reflection,
most of which is the construction of an Object array to pass to Method.invoke().
That's not to say the difference is unimportant.
If you have to parse lots of xml, it will definitely add up over time.
e.g. See my 0.4 seconds from 2.4 seconds estimate above (which is probably not
all reflection overhead anyway?) -
26. Re: XB profiling during the AS start-up
Maybe it is classloading that is the culprit? Fast-jaxb has no binding time, but the first time you parse requires loading classes. Each JAXB annotated class = 1 Parser class in the model I created. Since JAXB already has had its classes loaded at bind time, this overhead isn't accounted for in the test.
-
27. Re: XB profiling during the AS start-up
"bill.burke@jboss.com" wrote:
Maybe it is classloading that is the culprit? Fast-jaxb has no binding time, but the first time you parse requires loading classes. Each JAXB annotated class = 1 Parser class in the model I created. Since JAXB already has had its classes loaded at bind time, this overhead isn't accounted for in the test.
I doubt that would make a difference for this test since I think there are only 2 classes?
It shouldn't take 0.8 seconds to do that. ;-)
But it also wouldn't be a fair test if you excluded the extra classloading time from the
numbers. We want to know which is faster in the real world. The overhead of
the extra classes are an argument against the code generation in that case. -
28. Re: XB profiling during the AS start-up
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.
-
29. Re: XB profiling during the AS start-up
"adrian@jboss.org" wrote:
"jason.greene@jboss.com" wrote:
and it can do direct method invocation as opposed to reflection which is definitely faster.
I think you'll find that that is probably not as relevant as you think.
This is a similar problem to Serialization.
The time it takes to
1) decide what to do - typically a string comparison on an element or attribute name
2) coerce xml data into non-string types
will likely "swamp" the small amount of extra time it takes to invoke a setter via reflection,
most of which is the construction of an Object array to pass to Method.invoke().
That's not to say the difference is unimportant.
If you have to parse lots of xml, it will definitely add up over time.
Yes you have a point, it may not be that faster for one parse. However, reflection does involve all kinds of initial caching on the first invocation, so maybe it will have some small but measurable impact. It should definitely not be slower though which is really what i was driving at.
e.g. See my 0.4 seconds from 2.4 seconds estimate above (which is probably not
all reflection overhead anyway?)
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.