Steve Loughran wrote:
I suspect reflection doesn't really have much impact in the Axis framework. When I looked into some of the performance issues back in December (mainly with respect to large messages) I didn't find any one aspect that was causing a big performance hit (aside from a bug in the namespace handling, which now has a workaround in place). A lot of the internal Axis structure is constrained by JAX-RPC compatibility, and that makes it really difficult to implement big performance improvements. For instance, JAX-RPC is based on SAX parsing which is pretty horrible for structured data - you have to maintain state in your handlers, and figure out what to do with each document component that gets delivered to you. A pull parser approach would be *much* more efficient for SOAP - but would be incompatible with JAX-RPC. Alek Slominski was working in this area before he got into the WSIF stuff, don't know what's going on with it now: http://www.extreme.indiana.edu/xgws/xsoap/ (and the paper at http://www.extreme.indiana.edu/xgws/papers/sc00_paper/index.html).I suspect that the use of reflection has a lot to do with the issue. Java platforms use reflection to enable a bunch of dynamic features which are really hard to reproduce in a C++ environment. You'll find this to be true in SOAP platforms, servlet engines, and J2EE servers.I think Axis only reflects in the java invocation phase, and in serialisation/deserialisation of stuff. I bet the latter aspect of marshalling is the slowest bit of the process...and wonder how hard it would be to autogen the code to do the binding.
There *does* seem to be a lot of memory churn going on with Axis. Running the client with -verbose:gc I saw a total of about 18MB garbage on the client side for round-tripping a 320KB message - you can see full details in the archive at http://marc.theaimsgroup.com/?l=axis-user&m=103825449231468&w=2. Reducing unnecessary object creation would certainly help performance.
Just in passing, one particular area that I suspect causes performance problems is the SAX event stream buffering that gets done for multiRefs in RPC encoded messages. This is an intriguing approach - if you need a reference to an object that's not defined yet, just skip ahead in the event stream to get the object definition, then continue on from where you are now. I suspect it'd be considerably faster (and simpler) to just create an object to track the forward reference, then fill it in when the reference is defined. This may be another area where the behavior is requried by JAX-RPC, though.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com
Redmond, WA 425.885.7197
