cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: JProfile Results on CXF startup
Date Fri, 14 Mar 2008 19:08:55 GMT


> Looking for time not (obviously) connected to JAXB, my next sad report
> concerns XmlSchema. Consider a simple JAX-WS+JAXB client endpoint with
> a WSDL. It reads and parses the WSDL, and builds the service model.
> Building the service model did not appear as a significant time sink.
> Parsing the WSDL file did ... because XML schema's namespace
> resolution mechanism turns out to be a significant hotspot.

Oh, yea.    I remember that from the last time I profiled things.  Kept 
meaning to bug Dan into fixing that.   It really might be worth starting 
to submit a bunch of patches to XmlSchema to fix things in hoping to 
become a committer.   We may actually be able to get releases done 
then.  :-(


> Caching the parsed form of a WSDL seems a plausible thing to do,

Umm...  we DO cache the parsed wsdl.   We don't cache the parsed 
XmlSchema. 

> except that I'm personally quite aware that the process of building
> the service model includes filling gaps that turn up in the schema.
> Also, in theory, the WSDL could *change* from one Endpoint creation to
> the next, could it not? 

Well, I think the only changes would be additions that would not impact 
other endpoints that are using the schema.   Basically, we may add 
wrapper elements/types, we may add elements that point to types (for 
headers), that's probably it.  Thus, we probably could cache it.  
(although we may need to start syncing on the schema if the XmlSchema 
api's aren't thread safe (I immagine they aren't).


> I think it would be a good thing if some others would join the
> discussion here about what, if anything, to do next. At one level, we
> could focus on making performance tests part of the standard (or an
> optional) build, to ensure that we don't code big performance
> regressions. Or we could aim at some of the issues discussed above. Or
> I could make more measurements.



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message