This seems to be a simple RTFM issue to me: POSIX specifies that gmtime() uses UTC and localtime() uses current timezone. Using gmtime() would implement the desired behaviour without any need to hardcode environment variables.
How setting the TZ environment variable avoids thousands of system calls
51–60 of 148 posts
Re: How setting the TZ environment variable avoids thousands of system calls
#52Earlier quoted context omitted.
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...
That's not how I read TZSET(3). According to TZSET(3) you can either use (example for Copenhagen shown) TZ=CET or TZ=:Europe/Copenhagen but not TZ=Europe/Copenhagen
Apologies, I didn't explain my response very well.
You're totally right to say that in the context of TZSET, to load the timezone specification from a TZ-formatted file it needs to be prefixed with ':'.
Rather than saying "Technically, you should set the value of TZ to 'Europe/London'", I was trying to say that my philosophical opinion of timezone recording - whether in a CMS, on an O/S level, in a compiled app, etc - is that it should start with the standard of geographical location.
There might be occasions to augment that with other data, maybe including the UTC offset for that TZ at a particular time, but the TZ specification can be subject to frequent change, whilst a description such as "Europe/London" changes infrequently and seems to have the least ambiguity.
Re: How setting the TZ environment variable avoids thousands of system calls
#53System 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 .…
System calls in x86 are fast. Other archs behave differently. And the syscall time is not the only thing that matters, but potentially yielding execution
Re: How setting the TZ environment variable avoids thousands of system calls
#54System 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 .…
On your base system, yes. Lots of things can hook random syscalls, or environments might have syscall monitoring. One example is the folks over at slack record every syscall for security auditing. https://slack.engineering/syscall-auditing-at-scale-e6a3ca8a...
Slack uses the Linux audit subsystem which is also certainly faster than you think it is. Consider how many system calls your typical application is issuing --- especially ones that are likely to be calling localtime() all the time, such as a web server. If system call auditing had that high of an overhead, everything would be horrifically slow --- but it isn't, because Linux audit sends its records out asynchronously and in batches.
Re: How setting the TZ environment variable avoids thousands of system calls
#55This reads to me like a glibc bug. Glibc should just be watching "/etc/localtime" for changes, rather than calling out to hundreds of times a second.
Re: How setting the TZ environment variable avoids thousands of system calls
#56System 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 .…
> System 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.
"fast" is a relative term, and is somewhat orthogonal to "efficient".
There's a reason why certain functions use a vDSO. If you're just going to use a syscall anyway, there's kind of no point.
Re: How setting the TZ environment variable avoids thousands of system calls
#57This seems to be a simple RTFM issue to me: POSIX specifies that gmtime() uses UTC and localtime() uses current timezone. Using gmtime() would implement the desired behaviour without any need to hardcode environment variables.
...which fixes all the code you wrote, but of course, you may have legacy binaries that you don't have access to source to change... hence a simple setting of an environment variable, hardcoded though it may be, fixes the situation for all.
Though PeterWillis makes a good point akin to yours, and your (plural) point does make sense.
(Edit: added mention of comment with additional background on why to avoid hardcoding the variable)
Re: How setting the TZ environment variable avoids thousands of system calls
#58While trying to find the cause of slowness in Rails requests, I was running strace on an unicorn process when I encountered the same thing mentioned in the article.
Rails instrumentation code calls current time before and after any instrumentation block. So, when I looked at the trace there were a lot of `stat` calls coming for `/etc/localtime` and as stat is an IO operation, I thought I discovered the cause of slowness(which I attributed to high number of IO ops) but surprisingly when I saw the strace method summary; while the call count was high, the time taken by the calls in total was not significant(Also, I think he should have printed the aggregate summary of just CPU clock time(`-c`) as well as that is usually very low.
Re: How setting the TZ environment variable avoids thousands of system calls
#59> 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…
Those who quote George Santayana are condemned to repeat him.
Those who don't know George Santayana are condemned to repeat him. FTFY.
Re: How setting the TZ environment variable avoids thousands of system calls
#60This reads to me like a glibc bug. Glibc should just be watching "/etc/localtime" for changes, rather than calling out to hundreds of times a second.
And how does it watch it? With the stat() syscall.