ファイルからLocalDateTimeを最も効率的に書き込んで読み込む

Question

LocalDateTimeインスタンスをファイルに書き込んでファイルから読み込み、LocalDateTimeオブジェクトに変換する最も速い方法は何ですか？

ミリ秒を保存してからDateオブジェクトに変換しました。 Java 8のLocalDateTimeを扱っていますが、これをファイルから保存して取り出す最も効率的な方法が何であるかは不明です。

Stringに変換してからStringに解析するためには、より多くのリソースが必要なので、DateTimeFormaterを使用するのは良い考えです。

タイムゾーンは関係ありません。

Answer 1

ミリ秒を保存したい場合は、java.time.Instantクラスを使用することができます。LocalDateTimeのみがタイムゾーン/オフセット情報を持たないので、ミリ秒を得る方法はありません。

// get the current date 
Instant instant = Instant.now(); 

// get milliseconds (equivalent to java.util.Date.getTime()) 
long millis = instant.toEpochMilli(); 

// get Instant from milliseconds 
Instant instant = Instant.ofEpochMilli(millis); 

---

あなたはLocalDateTimeを持っている場合は、しかし、あなたは簡単Instantに変換することができます

LocalDateTime d = LocalDateTime.now(); 
Instant instant = d.atOffset(ZoneOffset.UTC).toInstant(); 

このコードは明らかにLocalDateTimeの値はUTCの日付に対応することを前提とし、時間。バックLocalDateTimeからInstantを変換するには：

LocalDateTime d = LocalDateTime.ofInstant(instant, ZoneOffset.UTC); 

---

PS：あなたは「速い」は本当に問題であるかどうかを知るために、システムのパフォーマンスを測定していますか？とにかく、私は「標準」方法（APIが提供するものに基づいて最も単純な方法）をやっています、それはあなたが望むものですか？

Instantを「仲介」オブジェクトとして作成すると、「速く」なることは少ないと思われるかもしれませんが、とにかくそれを測定する必要があります。

// get the current date 
LocalDateTime d = LocalDateTime.now(); 
// get milliseconds value 
long millis = d.toEpochSecond(ZoneOffset.UTC) * 1000 + d.get(ChronoField.MILLI_OF_SECOND); 

// get LocalDateTime from millis 
LocalDateTime d = LocalDateTime.ofEpochSecond(millis/1000, (int) (millis % 1000) * 1000000, ZoneOffset.UTC); 

それはとてもミリ秒を取得し、java.timeクラスはナノ秒の精度を持っていることに注意することが重要です。そのような場合、あなたは（それがUTCの日付と時刻に対応することを想定して）直接LocalDateTimeからミリ秒を取得することができますこの精度を失うことになります。

あなたはナノ秒の精度を失うことを、必ずしもミリ値で作業する必要はありませんしたくない場合は、2つの異なる数字（エポック日当日のとナノ）保存することができます：

を

// get the current date 
LocalDateTime d = LocalDateTime.now(); 

// get values from LocalDateTime 
long epochDay = d.toLocalDate().toEpochDay(); 
long nanoOfDay = d.toLocalTime().toNanoOfDay(); 
// save both values to file 

// retrieve the LocalDateTime from the values 
LocalDateTime d = LocalDateTime.of(LocalDate.ofEpochDay(epochDay), LocalTime.ofNanoOfDay(nanoOfDay)); 

これはUTCへの変換を必要としませんが、1つではなく2つの数字が必要です。 LocalDateとLocalTimeを作成すると処理が遅くなると思われるかもしれませんが、これらの2つのオブジェクトはで常にで作成されたです（いずれの場合も）。

しかし、この計算がすべてInstantを使用するよりも「高速」であるかどうかはわかりません。あなたのケースに最も適しているかどうかを調べることはテストの問題です。明快さとコード-簡単に維持するという点で

しかし、私にとって、最も「効率的に」Instant（または日のエポック日とナノの最後のアプローチを使用して）を使用しています。何百万ものレコードを扱っていない限り、それが実際にパフォーマンスの問題になるかどうかはわかりません。

---

私は簡単なテスト（千万倍以上の各ケースを実行します）、および（エポック日日のナノ使用して）最後のアプローチを作った最速のようです。しかし、その差は1秒未満です。 2を実行することによってのみ億回私は20秒の違いを持っ​​ているので、あなたはこの多くのレコードを扱っている場合、多分それは価値がある。

他のリソース（メモリ使用量、CPU、I/O）に関して、私はチェックしませんでした。しかし、とにかく、パフォーマンスの問題は、システムがどのように設計されているか、システムの部品/モジュール/コンポーネントが相互にやりとりする方法、およびその他の多くの要因によって、各状況に異なるボトルネックが発生する可能性があります。

最終的には、それぞれのアプローチをテストして、どれがシステムで最もよく機能するかを確認する必要があります。あるいは、それが大きな違いをもたらさないと結論づけることができます（数千万レコード未満の場合は、そうではないかもしれませんが、ベンチマーク後にのみ知ることができます）。