GDateTime usage opens, mmaps, faults, /etc/localtime on main thread
Each time we create a GDateTime
using the local timezone GLib will create it using g_time_zone_new_local()
. If the TZ
environment variable is not set, we don't really have any chance of caching that value (and older GLib's don't even try). The problem with this is that creating a local GTimeZone
is actually a decent amount of work. It has to open("/etc/localtime")
, mmap()
it, and parse the results.
It would be nice if we could avoid those operations and inevitable TLB shoot-downs on the compositor thread.
We can cache the result of g_time_zone_new_local()
and then use g_date_time_new_now()
so long as we clear the cache on GnomeDesktop.WallClock::notify::timezone
. In older Shell releases, this is easy because we only ever call shell_util_format_date()
with the current time. Someone will need to check up a bit more for master.
I can provide a patch to 3.28.3 which will fix this up there and get rid of all but 1 /etc/localtime access that I've seen while doing some triage there.