Hi Kohsuke and Kenny,
I have a pretty big schema and I was able to get it to run through the
NetBeans profiler. Here's what I found.
The schema is about 1.2 MB of XSDs. This generates about 2.5 MB of
Java source and 891 KB of Java class files. On my test machine,
JAXBContext.newInstance takes around 4,031 ms. I wrote a simple app
which just does a JAXBContext.newInstance and ran it through the
Netbeans profiler. The profiler says running the app took 28520 ms.
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate : 18204 ms
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet : 9993 ms
Inside getOrCreate:
java.lang.reflect.Constructor.newInstance : 10390 ms
com.sun.xml.bind.v2.runtime.property.AttributeProperty.<init> : 7450 ms
Deep down in getTypeInfoSet:
com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo : 8512 ms
There's a rough view. I have uploaded the Netbeans Profiler custom
file output to here:
http://www.eonomine.com/jaxbperf.nps
I'm a Netbeans Profiler newbie, so I'm not sure how useful that NPS
file is to someone without the rest of my stuff. The schema I'm using
is very real-world, but not proprietary, so I can package it all up
along with my simple build.xml file if that would be helpful.
Regards,
--Eric
On 11/6/06, Kenny MacLeod <kennym_at_kizoom.com> wrote:
> Good idea. I'll pass my monster schema through a profiler and see what
> turns up.
>
> Any improvement in startup time would be appreciated!
>
>
> Kohsuke Kawaguchi wrote:
> > Kenny MacLeod wrote:
> >> A have a slightly unusual request here, but what would be involved in
> >> making com.sun.xml.bind.v2.runtime.JaxbContextImpl serializable?
> >>
> >> I ask because I'm playing with writing a mechanism which can serialize
> >> the context to a disk file in order to improve application startup
> >> time (JAXBContext construction for a complex schema is *very* expensive).
> >>
> >> I could just use an alternative serialization mechanism which doesn't
> >> require java.iot.Serializable (e.g. JBoss Serialization or XStream),
> >> but I'd rather just use vanilla java.
> >
> > Making JAXBContext serializable is an interesting idea. I'll go ahead
> > and implement it.
> >
> > However, because the serialization has to be compatible with future
> > changes, and due to the nature of what JAXBRIContext holds on to
> > (synthesized classes, etc), it is unlikely that you'll gain any
> > performance improvement out of it, compared to JAXBContext.newInstance()
> > --- in fact, in all likelihood what I'll implement in
> > readObject/writeObject would be just to invoke JAXBContext.newInstance()
> > again.
> >
> > Now, we do realize that the start-up performance of the RI has a
> > problem. This has been mostly because our benchmark metric is usually
> > driven by web service folks, where they care a lot more about the
> > sustained performance, so in a way our goal was skewed.
> >
> > Your post is very timely because I was actually thinking about
> > improvements in this area. Would you be interested in helping me? Like
> > if you can a benchmark and see which part of JAXBContext.newInstance()
> > is hot, that would really help me.
> >
> > I can do this on my own, by using some random schema, but I thought you
> > might like the idea that we are optimizing toward your schema!
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>