2011-11-17 14 views
5

Ho incontrato un enigma di prestazioni interessante ma prima di iniziare a scavare in glibc e inserire bug lasciati a destra e al centro, volevo solo ottenere qualche informazione che potesse esserci.performance strftime vs. snprintf

Ho codice che, in una delle funzioni fa questo:

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

Il resto del codice è irrilevante per questa domanda. Quando lo sostituisco con questo:

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); 

in media ottengo un aumento delle prestazioni del 20%.

Qualcuno si è imbattuto in questo? Questo sistema operativo è specifico?

+0

Quale sistema operativo/compilatore stai utilizzando? –

+3

Quindi 'snprintf' è più efficiente di' strftime' sul tuo sistema. Questo non sarebbe considerato un "bug". –

+6

'strftime' potrebbe avere a che fare con la localizzazione (più di' snprintf' fa). –

risposta

6

POSIX richiede strftime per chiamare tzset() (o si comporta come se lo facesse), che su un sistema Linux sarà probabilmente stat/etc/timezone e altri file, che è lento (rispetto a snprintf). L'impostazione della variabile di ambiente TZ generalmente darà un grande impulso.

Come è stato detto nei commenti, localizza anche il messaggio.

+0

L'impostazione della variabile di ambiente 'TZ' su un nome/percorso di zona probabilmente non aiuta, ma l'utilizzo di una descrizione di zona in stile POSIX come' EST5EDT, M3.2.0/2, M11.1.0/2' lo accelererà sicuramente (a scapito del supporto delle differenze storiche delle regole dell'ora legale). –

+0

Grazie. Ho effettivamente trovato che GLIBC 2.11 ha risolto questo problema. Non sono proprio sicuro di quale sia stata la prima versione che è accaduta. – Karlson