[JIRA] Issue Comment Edited: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.system... ] Ceki Gulcu edited comment on LBCLASSIC-36 at 6/14/09 9:38 PM: -------------------------------------------------------------- Thank you for this contribution. I have ran a modified (and simplified) version of your tests. It looks like SimpleDateFormat and Yoda time have roughly the same performance, with the former having the edge. Your version of the test had Yoda time transform Date objects. However, in logback, a "long" as obtained by System.currentMillis(), needs to be transformed. Transforming Date objects is pretty much beside the point, invalidating any argument made by the test you contributed. Just as importantly, logback will invoke Yoda time or SimpleDateformat, at most once per millisecond. So the performance of SimpleDateformat as well as Yoda time are as satisfactory as they are unimportant. Only the performance of System.currentMillis really matters. was (Author: noreply.ceki@qos.ch): Thank you for this contribution. I have ran a modified (and simplified) version of your tests. It looks like SimpleDateFormat and Yoda time have roughly the same performance. with the former having the edge. Your version of the test had Yoda time transform Date objects. However, in logback, a "long" as obtained by System.currentMillis(), needs to be transformed. Transforming Date objects is pretty much beside the point.
Synchronization of SimpleDateFormat object in DateConverter -----------------------------------------------------------
Key: LBCLASSIC-36 URL: http://jira.qos.ch/browse/LBCLASSIC-36 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: unspecified Environment: Operating System: All Platform: All Reporter: Anders Hammar Assignee: Ceki Gulcu Attachments: DateConverter_patch.java, dateformattest.zip
According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Ceki Gulcu (JIRA) skrev:
Just as importantly, logback will invoke Yoda time or SimpleDateformat, at most once per millisecond. So the performance of SimpleDateformat as well as Yoda time are as satisfactory as they are unimportant. Only the performance of System.currentMillis really matters.
"once per millisecond" does not merit unimportance as this might mean 1000 times per second. Would a reasonable optimization be "once per second" with the miliseconds being hacked in afterwards? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu (JIRA) skrev:
Just as importantly, logback will invoke Yoda time or SimpleDateformat, at most once per millisecond. So the performance of SimpleDateformat as well as Yoda time are as satisfactory as they are unimportant. Only the performance of System.currentMillis really matters.
"once per millisecond" does not merit unimportance as this might mean 1000 times per second.
True. However, keep in mind that the computation performed 1000 per second takes 2 microseconds.
Would a reasonable optimization be "once per second" with the miliseconds being hacked in afterwards?
Reasonable? Well, certainly! Assuming the 2 microsecond cost is too much (which I find iffy), we could add another conversion word, say, %optiTime, which would have a precision of a second but not milliseconds. For milliseconds, the user would use, say the %millis converter. This would gains us 2microseconds x 1000 per second, or 2 milliseconds per second, if the application was doing logging and nothing else. It's too much of a hassle and not worth the effort if you ask me. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu wrote:
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu (JIRA) skrev:
Just as importantly, logback will invoke Yoda time or SimpleDateformat, at most once per millisecond. So the performance of SimpleDateformat as well as Yoda time are as satisfactory as they are unimportant. Only the performance of System.currentMillis really matters.
"once per millisecond" does not merit unimportance as this might mean 1000 times per second.
True. However, keep in mind that the computation performed 1000 per second takes 2 microseconds.
To be clear, I meant to day that that particular computation takes *only* 2 microseconds, albeit it is performed 1000 times per second. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu skrev:
would use, say the %millis converter. This would gains us 2microseconds x 1000 per second, or 2 milliseconds per second, if the application was doing logging and nothing else.
It's too much of a hassle and not worth the effort if you ask me.
Every computation done in logging sets an upper limit on the amount of messages the system is capable per second. What is the upper limit on messages (with {}-replacements and all, you probably have the necessary stuff in place) per second when using the NOP-logger? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
participants (3)
-
Ceki Gulcu -
Ceki Gulcu (JIRA) -
Thorbjoern Ravn Andersen