There is one thread in our application frequently call the localtime_r. We found the thread performance has 20% drop when change the timezone from the America/New_york to Asia/Shanghai from the system(Redhat 6,). After profile, we found it is the localtime_r cause the difference. When set the timezone as America/New_york, the __tzfile_compute mainly call the __tzstring. While when set the timezone as the Asia/Shanghai the __tzfile_compute call the __tzset_parse_tz which consume most of the CPU time. I also do an simple test on our HP G8 server. 1 #include <time.h> 2 #include <stdio.h> 3 4 int main(void) 5 { 6 struct tm newtime; 7 time_t ltime; 8 char buf[50]; 9 10 for(int i=0;i<=1000000;i++) 11 { 12 ltime=time(<ime); 13 14 localtime_r(<ime, &newtime); 15 } 16 } After compile and run command time ./a.out with the timezone as Asia/Shanghai or America/New_York. Asia/Shanghai real 0m1.838s user 0m1.628s sys 0m0.206s America/New_York real 0m0.608s user 0m0.395s sys 0m0.211s There is no TZ env been set on both cases. I wonder what causes the performance so difference, is it an designed behavior? Steven
How do you set the timezone?
link the /etc/localtime to time zone under usr/share/zoneinfo/ e.g. ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
Please, have a look at this thread: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395 Don't know if it's the same bug, but seems to be very similar. There is a workaround that involves patching tzdata package (comment #6), which helped in that case with Russian timezones, and maybe will do for you. But I really think that fixing glibc is a correct way to resolve the problem, as it significantly affects performance under some workloads. Also there is some technical info mentioned in comment #4 that may help in resolving this bug.
The difference between America/New_York and Asia/Shanghai is that the former has transitions until far in the future, whereas the last transition of the latter was 1991, and later timestamps are computed from the embedded POSIX TZ string.
This glibc performance bug came up recently on the tz mailing list; see the thread "[tz] localtime_r multiple times slower for Europe/Moscow timezone" starting here: https://mm.icann.org/pipermail/tz/2023-January/032522.html That thread stems from the following Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395 Guy Harris diagnosed the problem as glibc not properly caching the expansion of the TZ string at the end of the TZif file. See: https://mm.icann.org/pipermail/tz/2023-January/032529.html This problem has grown in importance as many jurisdictions are now like Moscow, as they formerly had daylight saving but now no longer do. So this performance bug is more important now than it was years ago.
Most if not all of China and India are also now no longer on DST, which is why it happens with Asia/Shanghai.