8

高いパフォーマンスが要求されるメッセージ処理システムがあります。最近、最初のメッセージが後続のメッセージよりも何倍も長くかかることに気づきました。これがシステムを通過するときに、一連の変換とメッセージの拡張が発生します。その多くは、外部ライブラリを介して行われます。

この問題のプロファイルを作成し（callgrindを使用）、1つのメッセージの「実行」と多くのメッセージの「実行」を比較しました（比較のベースラインを提供します）。

私が見る主な違いは、関数「do_lookup_x」が膨大な時間を費やしていることです。この関数のさまざまな呼び出しを見ると、それらはすべて共通の関数_dl_runtime_resolveによって呼び出されているようです。この関数が何をするのかはわかりませんが、私には、これは、さまざまな共有ライブラリが初めて使用され、次にldによってメモリにロードされているように見えます。

これは正しい仮定ですか？バイナリは、使用の準備が整うまで共有ライブラリをメモリにロードしないため、最初のメッセージで大幅な速度低下が見られますが、後続のメッセージでは見られません。

これを回避するにはどうすればよいですか？

注：マイクロ秒スケールで動作します。

4

2 に答える 2

15

ld.so(8)マニュアルページの環境セクションから：

   LD_BIND_NOW
          (libc5;  glibc since 2.1.1) If set to a non-empty string, causes
          the dynamic linker to resolve all  symbols  at  program  startup
          instead  of deferring function call resolution to the point when
          they are first referenced.  This is useful when using  a  debug-
          ger.

だから、LD_BIND_NOW=y ./timesensitiveapp。

于 2010-06-15T22:17:49.660 に答える
4

Ignacio Vazquez-Abramsのランタイム提案の代わりに、リンク時に同じことを行うことができます。共有ライブラリをリンクするときは、-z nowフラグをリンカに渡します。

于 2010-06-16T05:23:23.427 に答える