同僚と私はこの問題について往復しています。提案されたソリューションが良いアイデアであるかどうかについていくつかの外部意見を得たいと考えています。DateTime.Nowの代替案の最適化
最初に、免責条項：「DateTime.Nowを最適化する」という概念は、あなたの一部に狂ったように聞こえることを認識しています。私は先制防御のカップルを持っている：
- 私は時々いつも言うそれらの人々は、と思われる「コンピュータが高速です。読みやすさ常には、最適化の前に来る」しかし、多くの場合、どこのパフォーマンスアプリケーションの開発経験から話していますそれは重要かもしれない、重要でないかもしれないです。私は可能な限り瞬時に起こることが必要であることを話しています。ナノ秒以内（特定の業種では、はとなります - 例えばリアルタイム高周波取引）。
- これを念頭に置いても、以下で説明する別のアプローチは、実際にはかなり読みやすいです。これは、奇妙なハックではなく、信頼性と高速で動作する単純な方法です。
- があります。
DateTime.Nowは、（相対的に言えば）です。以下の方法ははです。
今、質問自体に。
基本的に、テストでは、DateTime.Nowは約25ティック（約2.5マイクロ秒）の実行になります。もちろん、これは平均して数千から数百万回の呼び出しになります。最初の呼び出しは実際にはかなりの時間がかかり、その後の呼び出しははるかに高速です。しかし、それでもなお25ティックが平均です。
しかし、私の同僚と私は、DateTime.UtcNowの実行に要する時間が平均でわずか0.03マイクロ秒に短縮されていることに気付きました。以下のためのUTCオフセットを決定する、つまり
public static class FastDateTime {
public static TimeSpan LocalUtcOffset { get; private set; }
public static DateTime Now {
get { return DateTime.UtcNow + LocalUtcOffset; }
}
static FastDateTime() {
LocalUtcOffset = TimeZone.CurrentTimeZone.GetUtcOffset(DateTime.Now);
}
}
：
は夏時間に変更がある一方で、当社のアプリケーションが実行されることはありませんことを考えると、私の提案は、以下のクラスを作成することでした現地時間帯 - 起動時に - その時点から、DateTime.UtcNowの速度を利用して、現在の時刻をより速く得るためには、FastDateTime.Now。
アプリケーションが実行されている間（たとえば、アプリケーションが夜間に実行されている場合）にUTCオフセットが変更された場合は、この問題が発生することがありました。私がすでに述べたように、私たちのの場合、それは起こりません。
私の同僚は、これを行う方法については異なるアイデアを持っています。これは私がここで説明するにはあまりにも複雑です。最終的にまで私がと言うことができますが、私たちのアプローチのどちらも正確な結果を返すのですが、私のほうが少し速いです（約0.07マイクロ秒〜0.21マイクロ秒）。私が知りたいのは何
は次のとおりです。
- 私はここで何かが足りないのですか？アプリケーションが単一の日付の時間枠内でのみ実行される上記の事実を考えると、
FastDateTime.Nowは安全ですか？ - 他の誰かがおそらくさらにと思うことがありますか？現在の時間を取得する方法はありますか？逆の順序で答えるために
このような単純化を行う場合、DSTの移行は通常の監視であり、これは問題ではないと既に規定しています。それは、ガードされていない人々を捉えて、1インチも移動することなく、2つのタイムゾーンに自分たち（およびそのアプリケーションソフトウェア）が住んでいることを発見します。あなたのテストスイートがこれをキャッチする唯一の時間は、夏時間の移行中に起こる場合です。まれにしか発生しません（または、テストスイートの一部として嘲笑されます。希少なもの）。 – PaulMcG