一般的なGuiceのパフォーマンスガイドライン

Question

現在、Guiceとその拡張機能をかなり使用するコマンドラインツールがあります。

ツールの機能が完了した後、私はパフォーマンスが標準より低いと判断し、単純なhprofを使用してプロファイリングを開始しました。

これは、インジェクタを作成するだけで、パフォーマンス上の大きな問題であることを指摘しています。私は一般的にModulesで実際の仕事をしないで、Providersの計算集中的な作業を予約します...

Guiceの一般的なパフォーマンスガイドラインは何ですか？ @AssistedInjectとFactoryModuleBuildersの使用を避けるべきですか？できるだけ@Singletonsを避ける？すべてのバインディングが明示的で、JITバインディングを避けることを確認してください。

私はすべてを検索しましたが、本当に速いと言っている人以外の、Guiceの基本的なパフォーマンスにはあまり触れていません。

Answer 1

まず最初に、あなたの質問はたくさん残されています。 「サブスタンダード」とは何ですか？その意味をどのように決めましたか？それは任意ですか？それが遅すぎると思うユーザーがいますか？ユーザーのやりとりの結果を生み出すのに時間がかかりすぎるか、時間がかかりますか？

実際のコードを評価することなく、パフォーマンスの問題をデバッグするのは難しいです。私の経験から得たヒントを次に示します：

1. インジェクターは一度しか作成しないでください。私は、すべてのREST要求に対してインジェクタを作成しているプロジェクトを見ましたが、それは恐ろしいパフォーマンスでした。彼らがそれをやめたとき、彼らのAPIは15倍速くなりました。コードを通じて複数のインジェクタを作成する必要がある場合は、リファクタリングを強くお勧めします。

2. シングルトンはパフォーマンスには最適ですが、誤用しないでください。それらは一度しか作成されません。インジェクタを作成するとすぐに、またはオブジェクトグラフの中で何か別のものによって最初に要求されたときに、すぐに発生する可能性があります。

3. Guiceはリフレクトベースのライブラリであり、リフレクションは常に遅いと理解しています。 Guiceは、インジェクタを作成するときに、多くのリフレクションを犠牲にして、実行時に非常に速いという素晴らしい仕事をしています（項目1を参照）。あなたのアプリケーションで目に見える遅れが見られる場合、おそらくあなたが何か間違っていることを意味します。あなたはあなただけのGuiceのパフォーマンス「問題」を扱うことができないと判断した場合

最後に、あなたはSquare（バージョン1）とGoogle（バージョン2）からダガーなどの代替手段を試してみることができます。それはリフレクションの代わりにコード生成を使用するので、リフレクションコストはありませんが、フル機能ではなく拡張機能もありません。