That's pretty much the same hotspots I got from profiling my schema (570
XJC-generated types), although the balance is slightly different.
Around 45% spent in ModelBuilder.getTypeInfo(Ref), which drills down to
37% spent in ModelBuilder.getClassInfo(Object, Locatable).
The other big one is 37% spent in
JAXBContextImpl.getOrCreate(RuntimeClassInfo).
So it looks like reflection is the prime offender here, if I'm
understanding this correctly. Like Eric, my profiling skills is not
extraordinary.
Eric Crampton wrote:
> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>