Earlier quoted context omitted.
What I meant was: Currently my timezone is CET. In a month's time it will be CEST. If I have to set TZ to explicitly mirror that it will be a burden.
TZ may be set like this: TZ=:Europe/Copenhagen Replace Europe/Copenhagen with the appropriate entry from the list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones Usually, /etc/localtime is a symlink, as on my laptop: /etc/localtime -> /usr/share/zoneinfo/Europe/Copenhagen so TZ=:/etc/localtime has the same result. You can demonstrate that it takes account of changes to timezones: Normal time for London:…
How setting the TZ environment variable avoids thousands of system calls
41–50 of 148 posts
Re: How setting the TZ environment variable avoids thousands of system calls
#42It is perhaps out of scope of the article, but it sure would have been helpful to show how to set the TZ environment variable and what to set it to.
Its right there in middle of article (under "Preventing extraneous system calls" section): $ TZ=:/etc/localtime strace -ttT ./test
Re: How setting the TZ environment variable avoids thousands of system calls
#43Re: How setting the TZ environment variable avoids thousands of system calls
#44 $ ldd test
linux-vdso.so.1 => (0x00007ffd80baf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8844bf7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8844fbc000)
Any thoughts why the behavior would be different?Re: How setting the TZ environment variable avoids thousands of system calls
#45System calls in Linux are really fast. So saving "thousands" of system calls when /etc/localtime is in cache doesn't actually save that much actual CPU time. I ran an experiment where I timed the runtime of the sample program provided in the OP, except I changed the number of calls to localtime() from ten times to a million. I then timed the difference with and without export TZ=:/etc/localhost. The net savings was .…
This might be true for your system and libc, where the system calls make use of things like vDSO for gettimeofday go fast, but in general this isn't guaranteed at all. Even on x64, for certain libc implementations, like musl, if I recall correctly, syscalls are made the old fashioned way by trapping 0x80, which would mean you would see a much bigger effect by reducing the number of syscalls.
This can actually be a problem, since there are applications like git which assume stat is fast, and so it aggressively stat's all of the working files in the repository to check the mod times to see if anything has changed. That's fine on Linux, but it's a disaster on Windows, where the stat system call is dog-slow. Still, I'd call that a Windows bug, not a git bug.
Re: How setting the TZ environment variable avoids thousands of system calls
#46This reminds me of an article by Ted Unangst[1], in which he flattens the various libraries and abstractions to show how xterm (to cite one of many culprits) in one place is effectively doing:
if (poll() || poll())
while (poll()) {
/* ... */
}
In other words, if you don't know what your library/abstraction is doing, you can end up accidentally duplicating its work.Reminds me of some aphorism, "Those who do not learn from history..." ;)
[1] http://www.tedunangst.com/flak/post/accidentally-nonblocking
Re: How setting the TZ environment variable avoids thousands of system calls
#47It would be highly inconvenient to have to set this variable if you live in a country where you change the timezone twice a year due to summertime.
TZs should be defined in the form "Europe/London", "Asia/Beirut", "Pacific/Auckland", etc. Although the hour offset can change at extremely short notice (e.g. discontinuing Daylight Savings during Ramadan [1]), the timezone declaration (e.g. "Africa/Casablanca"), shouldn't need to change, just the underlying timezone database. [1] https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocc...
TZ=CET
or TZ=:Europe/Copenhagen
but not TZ=Europe/CopenhagenRe: How setting the TZ environment variable avoids thousands of system calls
#48Re: How setting the TZ environment variable avoids thousands of system calls
#49It would be highly inconvenient to have to set this variable if you live in a country where you change the timezone twice a year due to summertime.
Convert to local time only on the edges, and only for end users.
Re: How setting the TZ environment variable avoids thousands of system calls
#50> In other words: your system supports calling the time system call via the Linux kernel’s vDSO to avoid the cost of switching to the kernel. But, as soon as your program calls time, it calls localtime immediately after, which invokes a system call anyway. This reminds me of an article by Ted Unangst[1], in which he flattens the various libraries and abstractions to show how xterm (to cite one of many culprits) in on…