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.
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!
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?
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
> >>
> >
> >
>