This week's book giveaway is in the Programmer Certification forum. We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
if performance is critical, we usually suggest using (rich) log files, as this is the fastest logging protocol for production systems (except logging to memory of course, but this is only useful in certain situations). SmartInspect log files can of course also be opened and analyzed in the SmartInspect Console, just as if the Console had received the data in real-time via TCP or named pipes.
There are in my opinion two scenarios that should be considered when discussing logging performance: enabled and disabled logging. Especially if logging is disabled (for the entire application or just for certain modules / users), the performance impact of the logging code must be minimal. As we have designed SmartInspect especially with performance in mind, SmartInspect does two things to improve performance for disabled logging: The first thing is that every log method immediately exits when logging is disabled (either globally disabled or just a specific session). Another thing SmartInspect supports are format strings and parameters for most logging methods, resulting in increased performance when logging is disabled, as the parameters do not have to be converted to strings in this case and the string doesn't have to be built.
Of course, performance is also important when logging is enabled. The performance of course depends on which logging methods are used and how much is logged, but in general only very few applications and systems have such critical performance requirements that logging is problematic. We have created a few benchmarks that are available on our website (which have been created with .NET, but the Java results are very similar):
Please note that benchmarks haven't yet been updated to showcase the new named-pipes protocol for real-time logging, which is a lot faster than TCP. But the benchmark shows that SmartInspect can easily handle >100.000 simple log messages per second when logging to a log file, with measured times of approx. 0.3 - 1.5 μs per message.
Regarding instrumenting the source code: you would need to do this manually, as we currently have no automatic instrumentation tool. In our experience, however, most applications already benefit greatly from just adding logging code to key parts and modules (and adding additional code over time when necessary). Aspects oriented programming is indeed a very good fit for SmartInspect and we are working on providing support for popular implementations (a few customers are already using AOP).
Let me know what you think or if you have any other questions!