Daylight savings, costs CPU

World daylight savings map

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  >   ???:mktime (1x) [/lib64/]
EST.txt:  546,244  *  ???:mktime [/lib64/]
EST.txt:  542,350  >   ???:mktime (1x) [/lib64/]

EDT.txt:Profiled target:  ./test_mktime (PID 18878, part 1)
EDT.txt:    4,819  >   ???:mktime (1x) [/lib64/]
EDT.txt:   23,119  *  ???:mktime [/lib64/]

It is currently EDT.


Tags: , , , ,

One Response to “Daylight savings, costs CPU”

  1. jsarenik Says:

    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!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: