I ran some tests with JProfiler. I hit send too soon the first time. Result 1. Spring initialization is very slow. I had to initialize a simple JAXWS+JAXB entrypoint hundreds of times to stop seeing the cost of configuring the default bus via spring as the predominant cost. The big-ticket items here are XML parsing and classloading. If we get complaints about 'why does it take so long to set up even a simple service', I fear that we need to consider our options here. We might still want to use Spring, but we might want to see if there's anything we can do to grease the wheels.
Result 2: I ran the loop 1000 times. (note: of course, if you initialize your endpoint via spring, you will see spring as the dominant cost no matter what). Now, classloading is the big cost, in getRequestWrapper and getResponseWrapper. It sure would be easy to make the looping application faster by caching this, but that's not going to help in the real world unless we have a real world case of someone complaining about the performance of recreating the same endpoint over and over. If that was a use case, then a simple cache here would give things a shave and a haircut. After the time spent in the classloader (and particularly in the URL constructor, more on that later), the next culprit was JAXB. I was bemused to see that the big pile of time in the classloader was spent constructing URL objects, and then messing with File objects to look for files. Now, on the one hand, running in eclipse, we have a big classpath of directories, and if i was running the app with the classes all jarred up, it would get smaller. But how much smaller, I wonder? Does the JRE cache JAR files? What didn't even come close to showing up in the percentages was any of the meat of the ReflectionServiceFactoryBean. Ideas?
