cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject WARNING: very big commit coming later today....
Date Tue, 25 Aug 2009 13:40:37 GMT

Just a warning, if I can get all the tests passing, I have a big commit coming 
in today (although broken across a couple commits that will all come at once) 
that touches a LOT of stuff.

Basically, I'm trying to reduce the startup time.  Specifically, the 
"BusFactory.createDefaultBus()" time.    I've done some investigation and 
discovered a few things that are taking a lot of time:

1) JSR250 processing - this is actually fairly expensive the first time.   
Retrieving annotations is expensive and the JSR250 has to look at every field 
and method.   The second time a class is used it's fast (cached), but that 
initial startup sucks.   I've added a NoJSR250Annotations annotation that can 
be added to beans loaded from Spring to mark the class as not having any 
JSR250 annotations anywhere on it so the JSR250 processor can skip it.   I've 
added this annotation to a bunch of places where it can be added.  (not all 
beans can have it, obviously)   This alone has about a 20% boost.  

2) JAXB context creations - the JAXB based WSDL extensors are creating their 
JAXB context up front.   If those extensors are never used (example:  never 
use the CORBA binding) it's a pointless waste of time.   I'm changing them to 
create them only if needed for parsing/writing.   ,

3)  lazy-init="true"  - I'm going through all the cxf-extension-*.xml files 
and adding lazy-init="true" to almost everything.   I'm also updating other 
code to pull beans "if needed".   This has a huge affect of lower the number 
of beans created at startup.   Right now, a default bus creates 57 beans up 
front, right away (and every one is run through the JSR250 processor).    With 
some changes, I now have this down to 20 beans (and I think I can get it down 
closer to 15), with only 6 going through JSR250 processing.   

The major affect of (3) is a lot of stuff doesn't get loaded unless it's 
needed.  If it's needed, you'll take a hit later to get it loaded, but if it's 
not needed, it's not loaded.    For example, if you don't use WSDL's at all 
(purely code first cases or JAX-RS cases), the WSDLManager is never loaded and 
thus none of the WSDL extensors are loaded. 

The "downside" of (3) is that a bunch of tests now fail that I'm trying to fix 
up.    There are many tests that test if the "count" of registered things is a 
particular number, but now the number is either 0 or much less.   I need to 
update the tests to actually ask for things first to make sure they get 

Anyway, it's a pretty big patch that touches a lot of files.  Thus, the heads 
up warning.

Daniel Kulp

View raw message