11

以前、株式アプリケーション関連のソフトウェアを初めて設計したとき、株式java.util.Dateの日付/時刻情報を表すために使用することにしました。

後で、メソッドのほとんどjava.util.Dateが非推奨になっていることに気付きました。したがって、すぐにすべてのコードをリファクタリングして、java.util.Calendar

ただし、私が遭遇する2つの欠点があります。

  1. コンストラクトjava.util.Calendarは比較的遅いjava.util.Date
  2. クラスのアクセサー getCalendar メソッド内で、変更可能なクラスStockと同様に、コピーを複製する必要がありますCalendar

Stock.javaの現在のソース コードは次のとおりです。

最近Joda-Timeを発見。java.util.Date1,000,000を作成して、次のベンチマークを行いjava.util.Calendarますorg.joda.time.DateTime。インスタンス化中に、org.joda.time.DateTimeよりも優れたパフォーマンスを発揮することがわかりました。java.util.Calendar

ベンチマーク代替テキスト結果はこちら。

このインスタンス化速度は重要です。特に、株式の長い価格履歴を表すために、多数の株式のインスタンスが作成されます。

アプリケーションの速度パフォーマンスを向上させるために、Java Calendar から Joda Date Time に移行する価値があると思いますか? 注意すべき罠はありますか？

4

5 に答える 5

12

も変更可能であることに注意してくださいjava.util.Date。したがって、現在使用しCalendarている で問題がある場合は、使用しても問題があったはずですDate。とはいえ、Joda Time を使用することは、はるかに優れた API であるという理由だけで、間違いなく価値があります。

特定のアプリでパフォーマンスが実際に問題になっていることをどの程度確信していますか? あなたは作成された「多くのインスタンス」があると言いますStock...いくつですか？プロファイリングしましたか？ほとんどの状況で実際に大きな違いが生じるとは思いません。ベンチマーク グラフからは、実際に測定しているものは明らかではありません。

Joda Time に移行することは一般的には良い考えですが、パフォーマンスを測定して、実際にどの程度の違いが生じるかを確認します。

于 2010-10-28T15:03:38.200 に答える
2

java.util.Calendar置き換えられるインスタンスがorg.joda.time.DateTime特定のパターンに解析および/またはフォーマットされている場合、たとえば

String format = "YYYY-MM-dd HH:mm:ss";
  1. パラメーターと戻り値の型のメソッド シグネチャ、および変数宣言内

インスタンス化、クラス名の単語全体のCalendar出現を置き換えます(

DateTime) およびSimpleDateFormat( を使用DateTimeFormatter)、それぞれ

  1. フォーマッタのインスタンス化ステートメントを置き換えます。

    formatter = new SimpleDateFormat(format);

    と

    formatter = DateTimeFormat.forPattern(format);

  2. `SimpleDateFormat' のメソッドへの呼び出しを置き換えます。

    String dateStr = formatter.format(Calendar.getInstance().getTime());

    と

    String dateStr = DateTime.now().toString(formatter);

    と

    formatter.parse(dateStr);

    と

    DateTime.parse(dateStr, formatter);
于 2016-07-08T14:08:12.707 に答える
2

なぜクラスCalendarにが必要なのですか? ある時点を表すためにStocka を使用しても問題ないと思います。Date非推奨のメソッドを無視する場合、ストック内のCalendarオブジェクトを不変にする必要があるため、これがDate必要なようです。クラスはそうあるべきです。

クラス外でCalendar時間操作を行う必要がある場合は、一時を使用できます。DateStock

Calendar calendar = Calendar.getInstance();
calendar.setTime(stock.getDate());
System.out.println(calendar.getYear());

Dateこのように、クラスにを引き続き格納できます。これは、データ ストレージからオブジェクトをStock格納および取得する場合にのみ最高のパフォーマンスを発揮するはずです。Stock一度に複数の操作を行う場合、同じCalendarオブジェクトを再利用することもできます。

インターフェイスが気に入らない場合Calendarでも、Joda Time を使用して時間操作を行うことができます。おそらく、必要に応じて日付を Joda Time に変換したり、Joda Time から変換したり、時間操作を行ったり、DateオブジェクトをStockクラスに保存したりできます。

于 2010-10-28T15:56:15.480 に答える
1

以前は Joda を使用していましたが、素晴らしいライブラリです。

残念ながら、パフォーマンスに関しては、テストする必要があります。しかし、コードのリファクタリングは多すぎるようです。個人的には、Dateアプリケーション全体 (DB ストアと取得を含む) で使用し、データ操作が必要な場合にのみ Joda を使用しました。Joda は必要な場合にのみフィールドを計算するため、オーバーヘッドは Java API クラスを使用するよりもはるかに低くなると思います。Dateさらに、 DB 内のオブジェクトを転送および処理したり、オブジェクトをシリアル化したりするためのオブジェクト バージョンの問題は発生しません。Joda がそのような互換性を壊すとは思いませんが、Date.

于 2010-10-28T15:11:07.410 に答える
0

一般的には、常に joda-time に移行することをお勧めします。しかし、プロジェクトの joda-time に移行することは、日付の使用に関するユースケースに基づいていることに本当に価値があります。一部の操作リンク テキストのパフォーマンス関連の数値については、プレゼンテーションのスライド 46 を参照してください。

于 2010-10-28T15:28:33.733 に答える