Daylight savings, costs CPU

Erik ran into a surprising performance problem over the weekend.

If you live in an orange area of the map, mktime(3) may be killing your performance.

tm_isdst is important. Don’t guess!

Don’t construct struct tm manually. Or, even better, let mktime decide DST for you. Set tm_isdst = -1.

Are you impacted? Run your programs under callgrind, vary between Standard and Daylight, and look at mktime’s profile. Using Erik’s jig,

$ TZ=EDT valgrind --tool=callgrind ./test_mktime
...
$ TZ=EST valgrind --tool=callgrind ./test_mktime
...
$ callgrind_annotate --inclusive=yes --tree=calling ...
...

$ grep "mktime " EST.txt EDT.txt 
EST.txt:Profiled target:  ./test_mktime (PID 29595, part 1)
EST.txt:    1,765  &gt;   ???:mktime (1x) [/lib64/libc-2.5.so]
EST.txt:  546,244  *  ???:mktime [/lib64/libc-2.5.so]
EST.txt:  542,350  &gt;   ???:mktime (1x) [/lib64/libc-2.5.so]

EDT.txt:Profiled target:  ./test_mktime (PID 18878, part 1)
EDT.txt:    4,819  &gt;   ???:mktime (1x) [/lib64/libc-2.5.so]
EDT.txt:   23,119  *  ???:mktime [/lib64/libc-2.5.so]

It is currently EDT.

Tags: Daylight savings, DST, mktime, Performance, tm_isdst

This entry was posted on March 20, 2012 at 8:56 am and is filed under Performance. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

One Response to “Daylight savings, costs CPU”

jsarenik Says:
March 21, 2012 at 4:28 am | Reply
Hi! Nice catch! Manual page mktime(3) mentions that “tm_isdst is set (regardless of its initial value) to a positive value or to 0…” so is this a glibc bug in the end? Greetings to Erik, Matt and the rest of the team!

Spinning