_dl_runtime_resolve - Когда общие объекты загружаются в память?

Question

У нас есть система обработки сообщений с высокими требованиями к производительности.Недавно мы заметили, что первое сообщение занимает много раз дольше, чем последующие сообщения.По мере того, как это происходит в нашей системе, происходит множество трансформаций и расширений сообщений, большая часть которых выполняется посредством внешней библиотеки.

Я только что профилировал эту проблему (используя callgrind), сравнивая «прогон» только одного сообщения с «прогоном» многих сообщений (обеспечивая базовый уровень сравнения).

Основное отличиеЯ вижу, что функция "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.