Last week the latest release of the Spring frame work was announced on the springframeworkdotorg website. Nothing special, just an .0.x bugfix and enhancement release, actually nothing exiting. So why is it worth a blog entry? Because of the curious announcement that spring bean creation has gone through tremendous performance improvements. Let me Quote: “Regarding the performance improvements, repeated creation of Spring bean instances is up to 12 times faster in this release than previous versions of Spring 2.0. AspectJ-based weaving performance has also increased by a significant factor. “.
Wow, twelve times! That is a pretty precise and accurate number! So not ten, not eleven but exactly twelve times faster! But to bad, my manager asked me to speed up bean creation time by a factor thirteen so I think I need to switch to Guice instead.
The problem in this statement is not the number itself but the fact a number is used to express improvements in an area the expresser has no full control. Currently I’m downloading both the 0.3 and 0.4 releases of Spring2 and my first conclusion is the 0.4 release is about 1.01 times bigger in terms of megabytes (off the record, 62.2 MB for a framework download is pretty fat). My second conclusion is the 0.4 release got downloaded 1.3 times faster. Both are facts, (it’s happening straight in front of me!) but the last fact does not express anything! There are too many factors that are influencing this magic number. Same with the 12 times faster statement. I won’t argue about the fact 2.0.4 has improved bean creation and I immediately believe there situations the number is matched by the comma. But personally, it says nothing to me: I’ll wake up when someone tells me the startup time of all my spring based apps have been square rooted. And even then I’ll point to the useless sleep statements in my constructors which are sitting there only to invalidate bold performance claims.
Note I’m not trying to nitpick on anything; every improvement is more than welcome, as long as my beans see the light, but this kind of statements are besides hollow, technically completely insignificant. Why not give insight *what* has been done to improve performance. Like:
- AbstractAutoProxyCreator caches advice information per bean, for efficient prototype creation with auto-proxying
- AnnotationAwareAspectJAutoProxyCreator caches Advisors for singleton @Aspect aspects, increasing performance
- BeanWrapperImpl mimimizes bean name parsing overhead and caches parsed property path tokens
- DefaultListableBeanFactory caches pre-converted property values as far as possible
- ConstructorResolver caches the resolved constructor or factory method, for faster re-creation of prototype instances
- ConstructorResolver caches converted argument values, to avoid conversion overhead for re-created prototype instances
(As one can see, ‘grep “cache” changelog.txt’ clarifies everything)
Nevertheless, I’m pretty happy with this release and I’m only writing this down as an advice for the upcoming 2.0.5! And now the changelog is still open on my desktop, I can end this blog entry by probably the most important enhancement:
- updated JRuby support for JRuby 0.9.8 !!
By the way, JRuby 0.9.8 claims IO sometimes to be 6.5 times faster ……
April 19th, 2007 at 2:35 pm
When we claim a “times” improvement in JRuby, we’re talking about specific benchmarks that are either widely-used in the Ruby world or fairly generic. In the case of IO, we managed to improve a number of file read/write benchmarks many times…on average the improvements meant those sorts of IO operations had improved by around 6.5 times over the previous release. This is interesting and important, since those IO operations were a known bottleneck in previous releases, and since this is a runtime concern, unlike Spring’s improvement at bean creation time (fairly rare in the grand scheme of execution, unlike IO).