users@jaxb.java.net

Re: Unmarshal performance

From: Torstein Hegbom <thegbom_at_sensewave.com>
Date: Fri, 22 Nov 2002 22:50:18 +0100

With greatest respect, and I hope you understand. It is my humble opinion that the JAXB package becomes somewhat teethless without a inheretance functionallity. Will there be a inheretance functionallity in the 2Q03 version?

regards,
torstein

----- Original Message -----
From: "Ryan Shoemaker - JavaSoft East" <Ryan.Shoemaker_at_Sun.COM>
To: <JAXB-INTEREST_at_JAVA.SUN.COM>
Sent: Thursday, November 21, 2002 5:33 PM
Subject: Re: Unmarshal performance


> 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
> >>>>
> >>>
> >>>
> >
>