Why glibc's fstat() is slow [LWN.net]

Why glibc's fstat() is slow

Posted Sep 14, 2023 17:37 UTC (Thu) by wsy (subscriber, #121706)
Parent article: Why glibc's fstat() is slow

glibc's localtime() is slow without TZ environment variable.

https://blog.packagecloud.io/set-environment-variable-sav...

to post comments

Why glibc's fstat() is slow

Posted Sep 14, 2023 19:07 UTC (Thu) by brenns10 (subscriber, #112114) [Link] (2 responses)

It's wild how many places that pops up! I fixed that in procps-ng where it would do a stat(/etc/local time) multiple times *per process* because of the printf formats being used. I'm sure tons of software, especially multithreaded apps, are experiencing this and slowdowns associated with it.

https://gitlab.com/procps-ng/procps/-/merge_requests/119

Why glibc's fstat() is slow

Posted Sep 14, 2023 21:56 UTC (Thu) by guillemj (subscriber, #49706) [Link]

There is https://sourceware.org/bugzilla/show_bug.cgi?id=24004 with a patch attached. You can use localtime_r(3) to avoid this problem. And at least for multithreaded code I'd expect it to be using that already, but otherwise other code might indeed suffer from this issue.

speed of repeated localtime() etc.

Posted Sep 16, 2023 0:30 UTC (Sat) by jreiser (subscriber, #11027) [Link]

Software which appends entries to a log file can call localtime (or its relatives) once per event, and there can be dozens or hundreds of events per second, for instance open(). In most cases the speed of logging can be improved by remembering the headway between the current gettimeofday() and the next future gettimeofday() when the relevant portion of localtime() can change. For an output format of HH:mm:ss, then the headway is limited to at most 1 second. For the local timezone, the minimum headway can be up to 30 minutes. If gettimeofday()still is within the headway, then there is no need to consult any any external authority.

Why glibc's fstat() is slow

Posted Sep 14, 2023 21:18 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (2 responses)

I despise the fact that POSIX insisted on standardizing the ugly TZ env variable as the standard interface for controlling timezones. It makes some amount of sense to have a process-wide value for "the local timezone." It makes considerably less sense to make that the *only* way of doing tz-aware calculations. If I want to know "what time is it in [some specific part of] Australia?", it does not necessarily follow that I want the whole process to think it is actually in Australia.

Why glibc's fstat() is slow

Posted Sep 15, 2023 0:42 UTC (Fri) by butlerm (guest, #13312) [Link]

tzalloc, tzfree, localtime_rz, ctime_rz (and a few others) would seem like fit candidates for POSIX standardization.

Why glibc's fstat() is slow

Posted Oct 4, 2023 16:31 UTC (Wed) by roblucid (guest, #48964) [Link]

POSIX was documenting a standard with compromise between vendors, not generally a group of developers, creating new specs.
Commercial vendors tend to embrace and extend which resulted in fragmenting the UNIX user base.