Live data from Hacker News

How setting the TZ environment variable avoids thousands of system calls

blog.packagecloud.io

41–50 of 148 posts

Re: How setting the TZ environment variable avoids thousands of system calls

#41

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:…

Thanks!

Re: How setting the TZ environment variable avoids thousands of system calls

#42

It 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

I can't believe I missed that! Thanks.

Re: How setting the TZ environment variable avoids thousands of system calls

#44
Interesting article but I can't reproduce the behavior on Ubuntu 16.01 LTS. I don't have TZ set (or anything locale-related for that matter). Here are the library dependencies:

  $ 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

#45
post #29
post #18

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. 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.

There is no vDSO for calls to stat(2). The claim in the article was that by setting the TZ environment variable to ":/etc/localtime", one could save "thousands" of stat system calls. Even for old-fashioned system calls where you use trap 0x80, Linux is still amazingly fast.

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

#46
> 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 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

discussed https://news.ycombinator.com/item?id=11847529

Re: How setting the TZ environment variable avoids thousands of system calls

#47
post #40

It 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...

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

Re: How setting the TZ environment variable avoids thousands of system calls

#48
post #10
post #7

Side note - why do some sites completely hide information about who is behind them? I couldn't find a single thing about that on their blog or main site.

All the links are in the footer of the page.

For what it's worth, they disappear if your browser isn't wide enough.

Re: How setting the TZ environment variable avoids thousands of system calls

#49

It 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.

Do all your work in UTC. Seriously, you'll be glad later.

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…

Those who quote George Santayana are condemned to repeat him.
Post reply on HN