4

私たちはかなり大きなサーバーアプリを開発しています。各アクションはログによって追跡されます。toString メソッドの呼び出しに関する多くのログがあります。残念ながら、それらのほとんどが必要ですが、製品で何が起こるかを追跡することはできません。toString メソッドを改善しようとするのは理にかなっていますか? たとえば、 toString の結果をメモリに入れ、フィールドが更新された場合は更新します。

example of my toString
public classs InMessage{
//declared 20+ fields
     @Override
      public String toString() {
       StringBuilder builder = new StringBuilder(this.getClass().getSimpleName());
       builder.append(": [");
       builder.append(super.toString());
       builder.append("; updateTime: ");
       builder.append(updateTime);
       //forexample 20 fields here
       builder.append(";]");
       return builder.toString();
     }}
then we process InMessage in some way and log each action
     log.debug("We received inMessage: {}", inMessage);

この議論の後、可能な限りログの数を減らすことに決めました。

4

2 に答える 2

8

パフォーマンスやメモリの問題が実際に発生していない限り、心配する必要はありません。有用なログは、製品の診断に非常に役立ちます。決して起こらないかもしれない仮説的なパフォーマンスの懸念と比較検討する必要があります。

(ここで間違いなく問題がないと言っているわけではありません。実際には問題ではないものを最適化しないでください...)

編集：「多すぎる」ログを記録しているかどうかについては、自分の判断を信頼してください。1 つの UI またはサービス操作で 20 ページの付随的 / デバッグ レベルの情報が生成される場合、たとえ INFO レベルのログ記録であっても、コンテンツを改良して真に役立つようにすることができます。

于 2013-02-14T13:53:49.333 に答える
3

そのナノ最適化は通常、数秒または場合によっては数分で処理される時間から差し引かれた数ミリ秒を除いて、全体的な価値を追加しない無駄な努力に終わります。ケースによって異なりますが、あなたのケースは、少しずつ重要なケースの 1 つになる可能性があります。

データに基づいて最適化の必要性を特定し、特にそのような方法で事前に最適化しないでください。likeの使用に疑問を呈するよりも価値があると証明できる他のアプローチがあるに違いありませんtoString。たとえば、一般的に使用されるアルゴリズムの順序を改善したり、操作の負荷を軽減したりします (呼び出しは少なくなりますが、重要なものです)。

の使用法を、考えているソリューションと比較してtoStringください。フィールドが変更された場合に中央の文字列リポジトリを更新する一種のオブザーバー パターンを実装していますか? これは、すべてのセッターでコードを実行しています (そのアプローチを使用する場合)。

于 2013-02-14T13:57:22.643 に答える