The application I’m currently working on is built around Spring. A couple of weeks ago, as I waited for it to start up for the 27th time that day, I began wondering if there was any way to get it to start faster. Coincidentally, our whole development team had just received upgraded laptops, so the fact that numbers are stagnating in the “Megahertz” department (but not in the “CPU cores” department) had been recently emphasized.
Further, I had just read a series of articles by Cédric Beust regarding recent improvements to the TestNG threading engine. In short, TestNG allows you to run tests on multiple threads in order to shorten the test suite run time. However, when you start creating tests with dependencies on other tests, TestNG punts and runs all of these groups of dependent tests serially, on a single thread. Cédric wanted to remove this limitation, and approached the enhancement as a topological sort problem, viewing the tests as nodes in a directed acyclic graph.
Most of the startup time in Spring-centric applications involves the initialization of singleton beans. It wasn’t too much of a mental leap to wonder if the same graph/sort approach could be applied to the application startup optimization question — with the Spring beans acting as the nodes in the graph, instead of the tests.
It turns out to be (sort of) possible, and (sort of) worth the time. I’ve posted the details, including the source, here. Feel free to check it out and make suggestions. The Spring framework does contain a very coarse lock that required a pretty horrible hack in order to get any performance gains out of the experiment, but once this is worked out I don’t see why an implementation of this approach couldn’t make it into real applications. Again, see the project page for more details.
On a side note, this is the first time that I’ve used GitHub to host any code, and I have to say that I really like the fact that the README file serves the dual purposes of local project documentation and homepage markup!
