2011-11-17 22 views
5

Me he encontrado con un enigma de rendimiento interesante, pero antes de empezar a profundizar en glibc y escribir errores a la derecha y al centro solo quería obtener alguna información que pudiera estar ahí.strftime performance vs. snprintf

que tienen código que en una de las funciones hace esto:

gettimeofday(&tv, 0); 
localtime_r(&tv.tv_sec, &local_tm); 
char result[25]; 
strftime(result, 24, "%Y-%m-%d %H:%M:%S", &local_tm); 

El resto del código es irrelevante para esta pregunta. Cuando lo reemplazo con esto:

gettimeofday(&tv, 0); 
localtime_r(&tv.tv_sec, &local_tm); 
char result[25]; 
snprintf(result, sizeof(result), "%04d-%02d-%02d %02d:%02d:%02d", 
     local_tm.tm_year+1900, local_tm.tm_mon+1, 
     local_tm.tm_mday, local_tm.tm_hour, local_tm.tm_min, 
     local_tm.tm_sec); 

en promedio recibo un aumento del rendimiento del 20%.

¿Alguien se encontró con esto? Es este sistema operativo específico?

+0

¿Qué sistema operativo/compilador está utilizando? –

+3

Así 'snprintf' es más eficiente que' strftime' en su sistema. Esto no se consideraría un "error". –

+6

'strftime' puede tener que ocuparse de la localización (más que' snprintf'). –

Respuesta

6

POSIX requiere strftime para llamar al tzset() (o actuar como si lo hiciera), que en un sistema Linux probablemente stat/etc/timezone y otros archivos, que es lento (en comparación con snprintf). Establecer la variable de entorno TZ generalmente le dará un gran impulso.

Como se dijo en los comentarios, también localiza el mensaje.

+0

Establecer la variable de entorno 'TZ' en un nombre/ruta de zona probablemente no ayude, pero usar una descripción de zona de estilo POSIX como' EST5EDT, M3.2.0/2, M11.1.0/2' ciertamente lo acelerará (a expensas de apoyar las diferencias históricas de la regla DST). –

+0

Gracias. De hecho, descubrí que GLIBC 2.11 tiene ese problema resuelto. No estoy seguro de cuál fue la primera versión que sucedió. – Karlson