_dl_runtime_resolve - ¿Cuándo los objetos compartidos se cargan en la memoria?

Question

Tenemos un sistema de procesamiento de mensajes con las demandas de alto rendimiento. Recientemente nos hemos dado cuenta de que el primer mensaje de toma muchas veces más larga que los mensajes posteriores. Un montón de transformación y mensaje de mejora sucede a medida que este pasa a través de nuestro sistema, gran parte de que se haga a través de lib externa.

acabo de perfilar este tema (usando Callgrind), comparando una "corrida" de un solo mensaje con un "funcionamiento" de los muchos mensajes (que proporciona una base de comparación).

La principal diferencia que veo es la función "do_lookup_x" tomar una gran cantidad de tiempo. En cuanto a las diversas llamadas a esta función, todos ellos parecen ser llamado por la función común: _dl_runtime_resolve. No está seguro de lo que hace esta función, pero para mí esto se parece a la primera vez que las distintas bibliotecas compartidas están siendo utilizados, y luego se cargan en la memoria por el LD.

¿Es esta una suposición correcta? Que el binario no se puede cargar las bibliotecas compartidas en la memoria hasta que se siendo preparado para su uso, por lo tanto, vamos a ver una desaceleración masiva en el primer mensaje, pero en ninguno de los posteriores?

¿Cómo hacemos para evitar esto?

Nota:. Operamos en la escala de microsegundos

Answer 1

Desde la página del ld.so(8), Medio ambiente :

   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.

Así, LD_BIND_NOW=y ./timesensitiveapp.

Answer 2

Como alternativa a de Ignacio Vazquez-Abrams tiempo de ejecución sugerencia , puede hacer lo mismo en tiempo de enlace. Al vincular su biblioteca compartida, pase el indicador -z now al enlazador.