[
https://issues.apache.org/jira/browse/LUCENENET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13393624#comment-13393624
]
Christopher Currens commented on LUCENENET-495:
-----------------------------------------------
Yeah, I noticed that new structure a few weeks ago. Definitely more powerful,
in that it keeps track of utc offset. DateTimeOffset.Now actually just calls
{{new DateTimeOffset(DateTime.Now)}}, so it doesn't help in this case.
Interestingly enough, this improves speed in Lucene enough, that it has exposed
other thread-safety issues in Lucene. Fortunately, I think it's only affecting
code specific to the test suite. Well, it's actually code in
CollectionHelpers, in Lucene.Net.Support, on AddIfNotContains(Hashtable,
object). However, the only usages I could find for that particular method, is
in Lucene.Net.Test.
> Use of DateTime.Now causes huge amount of System.Globalization.DaylightTime
> object allocations
> ----------------------------------------------------------------------------------------------
>
> Key: LUCENENET-495
> URL: https://issues.apache.org/jira/browse/LUCENENET-495
> Project: Lucene.Net
> Issue Type: Bug
> Components: Lucene.Net Core
> Affects Versions: Lucene.Net 2.9.4, Lucene.Net 3.0.3
> Reporter: Christopher Currens
> Assignee: Christopher Currens
> Priority: Critical
> Fix For: Lucene.Net 3.0.3
>
>
> This issue mostly just affects RAMDirectory. However, RAMFile and
> RAMOutputStream are used in other (all?) directory implementations, including
> FSDirectory types.
> In RAMOutputStream, the file last modified property for the RAMFile is
> updated when the stream is flushed. It's calculated using
> {{DateTime.Now.Ticks / TimeSpan.TicksPerMillisecond}}. I've read before that
> Microsoft has regretted making DateTime.Now a property instead of a method,
> and after seeing what it's doing, I'm starting to understand why.
> DateTime.Now is returning local time. In order for it to calculate that, it
> has to get the utf offset for the machine, which requires the creation of a
> _class_, System.Globalization.DaylightTime. This is bad for performance.
> Using code to write 10,000 small documents to an index (4kb sizes), it
> created 1,570,157 of these DaylightTime classes, a total of 62MB of extra
> memory...clearly RAMOutputStream.Flush() is called a lot.
> A fix I'd like to propose is to change the RAMFile from storing the
> LastModified date to UTC instead of local. DateTime.UtcNow doesn't create
> any additional objects and is very fast. For this small benchmark, the
> performance increase is 31%.
> I've set it to convert to local-time, when {{RAMDirectory.LastModified(string
> name)}} is called to make sure it has the same behavior (tests fail
> otherwise). Are there any other side-effects to making this change?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
