[logback-dev] [JIRA] Issue Comment Edited: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter

[Joern Huxhorn (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11194#action_11194 ] 

Joern Huxhorn edited comment on LBCLASSIC-36 at 6/17/09 11:34 AM:
------------------------------------------------------------------

Hi guys,

I've just changed the TestDateFormatOriginal due to LBGENERAL-29.
Instead of Date or DateTime a long is now used. This is a better representation of our problem, I think, since LoggingEvent contains the plain long and a new Date has to be created for SimpleDateFormat.

My changes are contained in the patch for LBGENERAL-29.

Below are my numbers for the following environment:
Maven version: 2.0.10
Java version: 1.6.0_13
OS name: "mac os x" version: "10.5.7" arch: "x86_64" Family: "mac"

Running ch.qos.logback.classic.issue.lbclassic36.TestDateFormatOriginal
Raw - JDK: 3227 ns Joda: 5098 ns - Difference: -57.97955%
Synchronized DateFormat: 0.1453 seconds
Unsynchronized DateFormat: 1.3796 seconds
ThreadLocal DateFormat: 0.0954 seconds
Joda DateTimeFormatter: 0.0893 seconds

I guess the bad numbers in case of Raw are caused by HotSpot compilation at that time :p

Concerning the technique to use:
Wouldn't it be possible to define an interface like
interface TimestampFormatter {
  String format(long timeStamp);
}
and support both ThreadLocal DateFormat and Joda DateTimeFormatter?
That way, Joda could be an optional dependency. If Joda would be present, the Joda implementation would be used. Otherwise ThreadLocalDateFormat could be used as a fallback. It's a speed increase of about 7% after all...


      was (Author: jhuxhorn):
    Hi guys,

I've just changed the TestDateFormatOriginal due to LBGENERAL-29.
Instead of Date or DateTime a long is now used. This is a better representation of our problem, I think, since LoggingEvent contains the plain long and a new Date has to be created for SimpleDateFormat.

My changes are contained in the patch for LBGENERAL-29.

Below are my numbers for the following environment:
Maven version: 2.0.10
Java version: 1.6.0_13
OS name: "mac os x" version: "10.5.7" arch: "x86_64" Family: "mac"

Running ch.qos.logback.classic.issue.lbclassic36.TestDateFormatOriginal
Raw - JDK: 3227 ns Joda: 5098 ns - Difference: -57.97955%
Synchronized DateFormat: 0.1453 seconds
Unsynchronized DateFormat: 1.3796 seconds
ThreadLocal DateFormat: 0.0954 seconds
Joda DateTimeFormatter: 0.0893 seconds

I guess the bad numbers in case of Raw are caused by HotSpot compilation at that time :p
  
> 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, DateFormatPerfTest.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