Hey Rob,
I don't want to discourage you from continuing the type of evaluation you are
performing on the RI, but I would like to politely remind you that it is a beta
implementation. We're working extremely hard trying to fully implement the
specification (moving from DTD's to XSchema is no small task). That is our
focus for the first release.
I'm not trying to imply that performance isn't important to us, because it is.
We simply haven't had time for any tuning up to this point, so it doesn't
suprise me that we're generating inefficient code in some areas. Detailed
analysis like yours will help us to identify areas that we need to improve,
so please continue to send us reports. Just try to understand that our first
priority is fully implementing the JAXB spec. We will try to address as many
performance and usability issues as possible before the next release.
Thanks again for the constructive feedback...
--Ryan
Rob Collins wrote:
> I have done some profiling.
>
> It looks like we are doing many linear searches in the space of all
> attribute names for every attribute we are unmarshalling. This is
> catastrophic for elements with many attributes. I don't know what is going
> on under the covers, but I can see that the implementation of goto1() is a
> disaster.
>
> Will this be addressed in FCS (or before)?
>
> Thanks,
> Rob
>
> CPU TIME (ms) BEGIN (total = 10180) Wed Nov 20 17:06:52 2002
> rank self accum count trace method
> 1 42.30% 42.30% 150996696 4771 java.lang.String.equals
> 2 32.46% 74.75% 3040243 4508
> com.sun.xml.bind.util.AttributesImpl.getIndex
> 3 3.63% 78.39% 3040243 4697
> com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.getAttribute
> 4 2.26% 80.65% 5897198 5025 java.lang.String.equals
> 5 2.16% 82.81% 3040243 4783 java.util.Stack.peek
> 6 1.96% 84.77% 1 5306 sun.awt.windows.WToolkit.eventLoop
> 7 1.38% 86.15% 3040243 4681 java.util.Vector.isEmpty
> 8 1.18% 87.33% 75995 4905
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.enterAttribute
> 9 1.08% 88.41% 892 3188
> org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement
> 10 1.08% 89.49% 3040243 4656 java.util.Vector.size
>
> TRACE 4771:
> java.lang.String.equals(String.java:Unknown line)
>
> com.sun.xml.bind.util.AttributesImpl.getIndex(AttributesImpl.java:Unknown
> line)
>
> com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.getAttribute(SAXUnm
> arshallerHandlerImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.leaveAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> TRACE 4508:
>
> com.sun.xml.bind.util.AttributesImpl.getIndex(AttributesImpl.java:Unknown
> line)
>
> com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.getAttribute(SAXUnm
> arshallerHandlerImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.leaveAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.consumeAttribute(SA
> XUnmarshallerHandlerImpl.java:Unknown line)
>
> TRACE 4697:
>
> com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.getAttribute(SAXUnm
> arshallerHandlerImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.leaveAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.consumeAttribute(SA
> XUnmarshallerHandlerImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> TRACE 5025:
> java.lang.String.equals(String.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.enterAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.consumeAttribute(SA
> XUnmarshallerHandlerImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
> com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowTypeImpl$Unmars
> haller.leaveAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>
>
>>-----Original Message-----
>>From: Kohsuke Kawaguchi [mailto:Kohsuke.Kawaguchi_at_Sun.COM]
>>Sent: Wednesday, November 20, 2002 4:00 PM
>>To: JAXB-INTEREST_at_JAVA.SUN.COM
>>Subject: Re: Unmarshal performance
>>
>>
>>
>>>I am evaluating the beta release and seem to be seeing horrible
>>>performance when I unmarshal a large XML file. The performance I am
>>>seeing is about 64KB of source XML per second. Is this to
>>
>>be expected?
>>
>>>Is this way out of whack for what other people are seeing?
>>
>>Is the FCS
>>
>>>going to be significantly faster? Any suggestions?
>>
>>The first thing I would suspect is that documents are either
>>referring to
>>external DTD through DOCTYPE or external schema files through
>>xsi:schemaLocation.
>>
>>The chances are that your XML parser is configured to retrieve those
>>files, parse them, and validate them before XML is parsed and
>>passed to
>>JAXB. Please note that most XML parsers are configured in this fashion
>>by default.
>>
>>This slows down parsing considerably since it involves in
>>additional I/O.
>>Is your CPU utilized 100% while you are measuring performance?
>>
>>I don't think JAXB RI is super fast, but 64KB/sec doesn't sound right,
>>neither.
>>
>>
>>regards,
>>--
>>Kohsuke KAWAGUCHI
>>Sun Microsystems kohsuke.kawaguchi_at_sun.com
>>
>
>