The Logback logging framework for Java is great, but one thing I personally miss when I compare it to its venerable Log4j ancestor is the property configurator. Sure, both XML and Groovy are more powerful and there are convenient converters that can produce configuration files based on the old Log4j property files, but what does it cost? XML is much more expensive than simple properties, not to mention loading an entire scripting engine!
I decided to find out. My test case is far from perfect, but it should at least give a hint. It is a simple program. It first measures the time in nanoseconds used for initializing logging; then it allocates memory in a loop in order to force garbage collections. After a few minutes and several collections it triggers a full gc, reports the amount of memory used and sleeps, making it possible to connect and perform additional measurements using jstat or jconsole or some other tool.
I ran the program ten times with each configuration and tested with the simple fallback configuration, which logs to the console, as well as a similar XML and Groovy configuration. The results were not very surprising.
Initialization with the simple configuration was roughly 100 ms. XML configuration required about 200 ms, doubling the startup time. Groovy needed a full second. Heap usage for the application was about 7M with the simple configurator, 10M with XML and 16M with Groovy. Finally, the permanent generation (classes and so on) was 4.4M with the simple configuration, 6.5M with XML and 13M with Groovy.
For an Enterprise application the overhead is trivial, I would worry more about the possible stability issues with a complex scripting engine than with the performance, but for a small application where startup time and footprint matters it makes sense to use a simple method. Perhaps a property-based configurator would be a good addition after all!