Estoy revisando una implementación de servidor que llama al tiempo (NULL) para cada solicitud que se procesa. Me pregunto qué impacto tiene el tiempo de llamada (NULL) en un sistema Linux típico y si hay comandos más baratos para determinar el día o, en general, ¿con qué frecuencia llamará a time()?¿Qué tan caro es el tiempo de llamada (NULL) en el bucle del servidor?
Gracias por su opinión sobre el tema.
Es una llamada al sistema, como ha dicho en otras respuestas, y las otras respuestas que dan una buena manera de medir el costo en su sistema. (Una vez en el kernel no tiene que hacer mucho trabajo, por lo que es bastante cercano al costo de la sobrecarga de syscall pura. Y Linux ha hecho todo lo posible para implementar llamadas de sistema de manera efectiva. En ese sentido, puede considerarlo bastante bien optimizado.)
a diferencia de las otras respuestas, yo no consideraría esto tan barato como para ser automáticamente no vale la pena preocuparse. Si esto está en un bucle interno, depende de qué más estás haciendo en tu bucle interno. Si se trata de un servidor que procesa solicitudes, es probable que realice muchas llamadas de sistema por solicitud, y una más, de hecho, no será un gran cambio en el costo de cada solicitud. Sin embargo, he visto código donde la sobrecarga de syscall de llamar a time() (o gettimeofday(), que es a lo que realmente se reduce) tiene un impacto perjudicial.
Si está preocupado por el costo, la siguiente cosa que preguntarse es qué maneras más baratas de encontrar el momento están disponibles. En general, no va a haber una buena forma más barata. Si está en x86, puede pedirle a la CPU la instrucción rdtsc (y es probable que haya un análogo en otras arquitecturas de CPU): es una instrucción de ensamblaje única que no tiene privilegios para que pueda colocarla en su código en cualquier lugar. Pero hay muchas trampas: rdtsc no siempre aumenta a una velocidad predecible, especialmente si la velocidad de la CPU cambia para la administración de energía, dependiendo del modelo preciso de la CPU que esté utilizando; los valores pueden no estar sincronizados a través de múltiples cpus, etc. El sistema operativo realiza un seguimiento de todo esto y le dará la versión amigable y fácil de usar de la información cuando llame a gettimeofday().
¿Es esta REALMENTE su cuello de botella? Sugeriría perfilar en su lugar. Obtener la hora actual es una operación común muy y dudo mucho que sea costosa (aunque podría escribir fácilmente un programa para medirla). Por ejemplo, todos los servidores web lo hacen en cada solicitud de sus archivos de registro.
Es solo un syscall sin mucho procesamiento en kernel. time() no hace ninguna diferencia si su servidor envía archivos al usuario, que toma 100 read()/write() s o hace algo como esto.
Obtención de la hora actual implica una llamada al sistema de Linux. Como sugested por Vilx, es bastante fácil de referencia:
#include <time.h>
int main(void)
{
int i;
for (i = 0; i < 10000000; i++)
time(NULL);
return 0;
}
La ejecución de este programa se lleva a 6.26s en mi endeble Atom a 1,6 GHz 330 con un núcleo de 64 bits, lo que equivale a aproximadamente 1002 ciclos de CPU por llamada (6.26s * 1.6G ciclos por segundo/10M iters ≈ 1002 ciclos).
Esto ciertamente no garantiza mucha preocupación, según lo observado por otros.
Seguramente no es un cuello de botella, pero me pregunto cuál es el impacto en términos de tiempo de procesamiento. Supongo que es una llamada altamente optimizada, pero me pregunto si alguien tiene una idea clara de esto. – anselm
@anselm - Dudo que alguien haya considerado antes esta función como un problema de rendimiento. ¿Por qué no lo comparas? –
Apuesto a que alguien tiene. Nunca he mirado 'time' específicamente, pero una vez tuve que comprobar el rendimiento de la función Java' System.getCurrentTimeMillis', porque un cliente afirmó que nuestra implementación era un cuello de botella.Lo cual no fue, debo agregar, simplemente no estaban analizando su propio código muy bien. Pero conseguir el tiempo del sistema fue realmente lento en Windows (varios ms IIRC, pero podría estar equivocado), y creo que es más rápido en Linux. Hace mucho tiempo, sin embargo. –