On Sep 26, 2011, at 12:43 AM, David Blevins wrote: > # JAXB Accessors > > One of the biggest polluters of the class space is JAXB as it generates > accessors for all the fields. First thought is, gee, I wonder if we can do > that at build time and keep the class definitions. If there's some way we > could write down those classes, it could save us a lot of trouble at runtime. > We'd get a great speed boost on the cold start -- which is where unit test > performance lives. > > A while back I did some perf testing of our OpenEJB 3.0 speed and JAXB was > nearly half of the time it took to boot. We have a bigger JAXB tree than we > did and that can easily account for a sliver of the slightly slower embedded > speed. > > The classes exist, so there has to be some way to write them to disk even if > there is no magical flag that will make the JAXB RI do it for us. Would be > great to know if such a flag did exist. If someone is looking for a research > problem, this would be a great one.
Did some work on this. https://issues.apache.org/jira/browse/TOMEE-143 With a JavaAgent, we monitor all classes created and their bytecode. Anything that is a "$JaxbAccessor" class is written to disk. The new openejb-jee-accessors module contains all these accessors. $ ls -lh target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar -rw-r--r-- 1 dblevins dblevins 596K Feb 26 15:48 target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | grep 'WebApp' 666 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_absoluteOrdering.class 608 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_contextParam.class 652 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_dataSource.class 610 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_distributable.class 654 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbLocalRef.class 644 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbRef.class 648 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_envEntry.class 602 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_errorPage.class 596 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_filter.class 610 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_filterMapping.class 640 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_icon.class 602 Sun Feb 26 15:48:22 PST 2012 org/apache/openejb/jee/WebApp$JaxbAccessorF_jspConfig.class [....] $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | grep -c 'class$' 966 Soo... all that and it doesn't seem to work :) mingus:~/openejb/examples 04:13:17 $ for n in simple-stateless* ; do (cd $n && mvn clean install); done | egrep 'Time elapsed|JAXBContext' Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.918 sec JAXBContext.newInstance 403 org.apache.openejb.jee.EjbJar Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.341 sec I think we're darn close though. I'd like to shift gears and work on more classpath scanning performance boosts, if someone wants to pickup this task and see what we might have to do to get JAXB to see the classes we've generated, that'd be great. Could shave half a second or a second off of even a simple test. -David
