[
https://issues.apache.org/jira/browse/LOG4NET-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101362#comment-13101362
]
Ron Grabowski commented on LOG4NET-151:
---------------------------------------
A further optimization might be to allow the user to set the timestamp
granularity at the log event generation stage for the repository. Some apps
might only care about logging events down to the second level rather than at
the millisecond level...or some fraction in between. Think SMALLDATETIME vs
DATETIME2 in SQL Server.
log4net.DateFormatter.AbsoluteTimeDateFormatter does this already when it
recognizes that it doesn't need to update the string representation of the
timestamp if nothing has changed from when it last generated. It also has the
lock() statement you mentioned.
Some other implementations might be:
- DefaultDateTime
Today's functionality using standard DateTime.Now or DateTime.UtcNow
- CachedDateTime
Cache DateTime.Now similar to AbsoluteTimeDateFormatter down to some user
specific granularity
- TickCountOffset
Record DateTime.Now once on startup then use Environment.TickCount to calculate
current time based on offset from start time. Another call to DateTime.Now must
take place as the offset nears Int32.MaxValue to avoid overflow. Maybe ~25
days??? This might help boost the performance of chatty apps that are always
recycled each day.
- Win32GetSystemTime
Maybe in FullTrust environments there are faster ways to get the current
time...or at least some numeric representation of the time that can then be
quickly turned into a real DateTime object without calling DateTime.Now
> Cache DateTime.Now values when creating LoggingEvent when
> Environment.TickCount has not changed
> -----------------------------------------------------------------------------------------------
>
> Key: LOG4NET-151
> URL: https://issues.apache.org/jira/browse/LOG4NET-151
> Project: Log4net
> Issue Type: Improvement
> Affects Versions: 1.2.10
> Reporter: Ron Grabowski
> Assignee: Ron Grabowski
> Priority: Minor
> Fix For: 1.2.11
>
>
> When creating a lot of logging events in tight loop, DateTime.Now is called
> for each new LoggingEvent even if several LoggingEvents are created within
> the same millisecond. We can reuse the same DateTime object because DateTime
> objects only track time down to the millisecond:
> // inspired by nlog
> int ticks = Environment.TickCount;
> if (ticks != cachedTicks)
> {
> cachedTicks = ticks;
> cachedDateTime = DateTime.Now;
> }
> return cachedDateTime;
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
