performance problem in Loader.reportUnexpectedChildElement

[glassfishrobot]

By profiling my application I found out a performance problem in the unmarshal
code. My test code parses a document 10 times.
The Unmarshaller.unmarshal(File) calls take 1484 ms while 1000 of them are spent
in the Loader.reportUnexpectedChildElement.

This is because the error message is formatted (MessageFormat.format) even
thought it will never be used because the error messages are not reported to the
user. Also you use the static call to MessageFormat.format that creates the
MessageFormat in every call.

By caching the MessageFormat object (using the code sample below) the
performance is much better (600ms).

private final ThreadLocal format = new ThreadLocal();
public String format( Object... args )

{ if( format.get() == null ) format.set(new MessageFormat(rb.getString(name()))); return format.get().format( args ); }

but it could be even better if you could avoid the message construction if there
is no error handler registered (the default option).

Environment

Operating System: All
Platform: All

Affected Versions

[2.0.4]

[glassfishrobot]

Reported by pkorros

[glassfishrobot]

Was assigned to jaxb-issues

[glassfishrobot]

kohsuke said:
Changing it to the enhancement.

[glassfishrobot]

pkorros said:
Today I found out another performance problem due to the fact that the
Loader.reportUnexpectedChildElement is computing both the error message and the
error location even when there is no error handler defined.

When the unmarshal method is called with an InputStream (and I guess many other
types) the Loader.reportUnexpectedChildElement method tries to find the error
location and this is leading to many MalformedURLException to be thrown taking
about the 80% of the time spent in unmarshal.

This is very important because, unmarshaling a jaxb object over an input stream
(socket, http, database etc) is the most common usage scenario for jaxb.
It makes DOM parsing more efficient for my case when jaxb should be much more
efficient than dom. Also I could not find a way to change this behavior without
patching the source code

A good solution would be not to compute the message and location at all when
there is no error handler registered.

[glassfishrobot]

pkorros said:
Any comments on this?

[glassfishrobot]

kohsuke said:
Fixed.

[glassfishrobot]

Marked as fixed on Tuesday, July 10th 2007, 3:27:03 am

[glassfishrobot]

This issue was imported from java.net JIRA JAXB-286