Rob Collins wrote:
> Ryan,
>
> Thanks for your response. I TOTALLY understand that this is a beta release,
> and if I implied that I don't think you guys are doing a great job, I
> apologize. The fact is that I am really excited by the promise of JAXB.
>
Rob,
Understood. I didn't think you were being hard on us...
> It would be really helpful to me if you could share the plan for dealing
> with this particular performance issue. For all I know, this is already
> fixed and you are planning another beta release tomorrow! If you are
> planning to address this sometime after 1Q03, then I need to implemented a
> workaround that I feel comfortable releasing in my code. If you are planning
> to release a fix in the next three weeks, then I don't need to worry about
> it at all. I would appreciate any plans you currently have. I understand
> that they are just plans, and not commitments!
>
I can't give specific dates, but I can tell you that we are not currently
planning on another beta release. Our current plan is to FCS mid 2Q03, but
that is subject to change based on what happens during the JCP process. We're
closing in on Proposed Final Draft of the specification, then there is a review
and voting process at the JCP. There are a number of things that could impact
our dates that are completely out of our control (ie non-Sun JCP issues).
> With regard to this specific issue, how can I best help make sure it gets
> addressed? Is this thread sufficient? Would you like me to file a bug
> report?
>
It would be helpful if you could file a bug for us. Also, please continue
to let us know if you uncover other performance issues or bugs that you would
like us to look into.
Thanks,
--Ryan
> Thanks again,
> Rob
>
>
>>-----Original Message-----
>>From: Ryan Shoemaker - JavaSoft East [mailto:Ryan.Shoemaker_at_Sun.COM]
>>Sent: Wednesday, November 20, 2002 5:46 PM
>>To: JAXB-INTEREST_at_JAVA.SUN.COM
>>Subject: Re: Unmarshal performance
>>
>>
>>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.ScreenSizeDepthRowT
>>ypeImpl$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.j
>>ava:Unknown
>>
>>>line)
>>>
>>>
>>
>>com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.getAt
>>tribute(SAXUnm
>>
>>>arshallerHandlerImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.leaveAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>TRACE 4508:
>>>
>>>
>>
>>com.sun.xml.bind.util.AttributesImpl.getIndex(AttributesImpl.j
>>ava:Unknown
>>
>>>line)
>>>
>>>
>>
>>com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.getAt
>>tribute(SAXUnm
>>
>>>arshallerHandlerImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.leaveAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>
>>
>>com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.consu
>>meAttribute(SA
>>
>>>XUnmarshallerHandlerImpl.java:Unknown line)
>>>
>>>TRACE 4697:
>>>
>>>
>>
>>com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.getAt
>>tribute(SAXUnm
>>
>>>arshallerHandlerImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.leaveAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>
>>
>>com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.consu
>>meAttribute(SA
>>
>>>XUnmarshallerHandlerImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>TRACE 5025:
>>> java.lang.String.equals(String.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.enterAttribute(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>
>>
>>com.sun.xml.bind.unmarshaller.SAXUnmarshallerHandlerImpl.consu
>>meAttribute(SA
>>
>>>XUnmarshallerHandlerImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$Unmars
>>
>>>haller.goto1(ScreenSizeDepthRowTypeImpl.java:Unknown line)
>>>
>>>
>>
>>com.limesoft.report.reportelementsxml.impl.ScreenSizeDepthRowT
>>ypeImpl$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
>>>>
>>>
>>>
>