3

I find mktime cost too much time on __tz_convert which will read /etc/localtime every time to get current timezone.

However, if we assume timezone never change, if only take one call to __tz_convert to get current timezone, which I think can reduce much time.

However, I wonder how to achieve this? There are no field in std::tm that I can put my timezone into. And I do not want to re-implement mktime from scratch, because seems it has lots of corner case, such as DST.

EDIT

... OR is it safe to just call __mktime_internal with a special __localtime_r that does nothing?

EDIT2

I think I may wrong about why mktime is slow in my case.

In my benchmark, most time are cost in __tz_convert, for a lock __libc_lock_lock (tzset_lock);. So maybe it is not related to cat /etc/localtime?

enter image description here

calvin
  • 2,125
  • 2
  • 21
  • 38
  • 2
    Wait for C++20 and use new and improved C++ timezone library? – ALX23z Aug 23 '21 at 08:18
  • 1
    Did you use a profiler to check that this is an actual performance bottleneck? According to `strace`, on my Arch Linux system, `/etc/localtime` is only _read_ once. Subsequent calls to `mktime` only trigger an `newfstatat` system call, presumably to check whether the file's modified timestamp has changed. If you call `mktime` frequently, the kernel will have this information cached, so there will be no disk access, only the overhead of the system call. – Thomas Aug 23 '21 at 08:34
  • Hi @Thomas, I have a benchmark which shows there are too much time cost in `__tz_convert`. That function will check `/etc/localtime` according to my searching(Maybe this searching is not correct, I have not checked that). – calvin Aug 23 '21 at 08:39
  • 1
    "*...is it safe to just call `__`*" - no, names starting with a double underscore are reserved for implementation and subject to change without notice. – rustyx Aug 23 '21 at 08:40
  • https://github.com/lattera/glibc/blob/895ef79e04a953cac1493863bcae29ad85657ee1/time/tzfile.c#L155 it should only `stat` it on subsequent calls. – KamilCuk Aug 23 '21 at 08:42
  • "However, if we assume timezone never change" what happens when your program is running during the night that DST switches? – Caleth Aug 23 '21 at 08:50
  • Those multiple "Edit" sections don't improve your question, rather the opposite. Aim for one coherent question. – Ulrich Eckhardt Aug 23 '21 at 08:51
  • @Caleth I think this cases are rare, and I can refresh timezone every hour if needed. – calvin Aug 23 '21 at 08:55
  • @UlrichEckhardt Ok, All I want is a solution to improve performance loss when `mktime` is frequently called. However, seems that I make I mistake on why `mktime` is slow in my case, if performance loss is caused by lock rather than sys call, maybe we should find another way, so I made a edit here. – calvin Aug 23 '21 at 08:58
  • "performance loss" compared to what? doing nothing? having wrong answers? If you are happy with those, I can suggest a 100% speedup – Caleth Aug 23 '21 at 08:59
  • @Caleth Yes, what if `__localtime_r` does nothing? Seems will reduce lots of time, I found it does nothing I need here. – calvin Aug 23 '21 at 09:01

0 Answers0