-
Bug
-
Resolution: Future Project
-
P4
-
6
-
x86
-
windows_nt
Run the attached application, LoggerPerfTest, in 3 modes:
java LoggerPerfTest
java LoggerPerfTest -logging
java LoggerPerfTest -logging -logSomething
The last two of these enabled logging by calling Logger.getLogger() and
the last test also outputs one logging call to this logger.
There is timing code in the application that times how long it takes to create the logger and, optionally, output a logging statement to that logger.
I find that on my system (Win2k, dual 800 MHz) it takes about 60 ms just
to enable logging. I do not find that it takes any extra time to also
output the single logging call.
I asume that most of this time is taken up by class loading (of the Logger
and its associated classes).
I can understand taking up time for Logging when the user has actually enabled it, but I do not think we should be taking up this much time when it is not even enabled. I would hope that we could do something quick to return a a simple logging class that did not drag in all of the related classes and functionality when that logger is not actually enabled. Since Logging is only going to be used in select situations, causing a 60 ms penalty for all users on the off-chance that it is enabled seems pretty steep.
I have also attached output from -verbose:class for all 3 runs above. You can see the extra classes loaded by the logging option versus the non-logging option. Note also that the loggingSomething run has no extra class loads (and also no extra time penalty).
Note that some of the classes loaded due to logging are not directly related
to Logging, per se (such as HashMap, etc.). So some of the penalty may be more severe in this noop application; were my application doing something more interesting (such as creating a GUI widget), then the delta between that run and a logging run might not be as large. I could not create such a case, however, because AWT is unfortunately dragging in Logging as it is, now, so I could not get demonstrate the Logger penalty under that situation. Nevertheless, the data is still valid; for very simple apps and configurations where Logging is not enabled, there should be no reason to drag in all of these extra classes.
java LoggerPerfTest
java LoggerPerfTest -logging
java LoggerPerfTest -logging -logSomething
The last two of these enabled logging by calling Logger.getLogger() and
the last test also outputs one logging call to this logger.
There is timing code in the application that times how long it takes to create the logger and, optionally, output a logging statement to that logger.
I find that on my system (Win2k, dual 800 MHz) it takes about 60 ms just
to enable logging. I do not find that it takes any extra time to also
output the single logging call.
I asume that most of this time is taken up by class loading (of the Logger
and its associated classes).
I can understand taking up time for Logging when the user has actually enabled it, but I do not think we should be taking up this much time when it is not even enabled. I would hope that we could do something quick to return a a simple logging class that did not drag in all of the related classes and functionality when that logger is not actually enabled. Since Logging is only going to be used in select situations, causing a 60 ms penalty for all users on the off-chance that it is enabled seems pretty steep.
I have also attached output from -verbose:class for all 3 runs above. You can see the extra classes loaded by the logging option versus the non-logging option. Note also that the loggingSomething run has no extra class loads (and also no extra time penalty).
Note that some of the classes loaded due to logging are not directly related
to Logging, per se (such as HashMap, etc.). So some of the penalty may be more severe in this noop application; were my application doing something more interesting (such as creating a GUI widget), then the delta between that run and a logging run might not be as large. I could not create such a case, however, because AWT is unfortunately dragging in Logging as it is, now, so I could not get demonstrate the Logger penalty under that situation. Nevertheless, the data is still valid; for very simple apps and configurations where Logging is not enabled, there should be no reason to drag in all of these extra classes.