_DL_RUNTIME_RESOLVE - 共有オブジェクトはいつメモリにロードされますか？

Question

高性能の需要を備えたメッセージ処理システムがあります。最近、最初のメッセージが後続のメッセージよりも何度も長くかかることに気付きました。これが私たちのシステムを通過するにつれて、変換とメッセージの増強の束が起こります。その多くは外部LIBによって行われます。

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

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

これは正しい仮定ですか？バイナリは、共有ライブラリが使用のために準備されるまでメモリにロードしないため、最初のメッセージで大規模な減速が表示されますが、その後はどれもありませんか？

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

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

Answer 1

から 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.

Answer 2

代替手段として イグナシオ・バスケス・アブラムのランタイムの提案, 、リンク時に同じことをすることができます。共有ライブラリをリンクするときは、渡します -z now リンカーへのフラグ。