Launchpad has imported 7 comments from the remote bug at https://sourceware.org/bugzilla/show_bug.cgi?id=15943.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-09-11T02:20:10+00:00 Qd-feng wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395/comments/7 ------------------------------------------------------------------------ On 2013-09-11T08:02:40+00:00 Andreas Schwab wrote: How do you set the timezone? Reply at: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395/comments/8 ------------------------------------------------------------------------ On 2013-09-11T08:16:23+00:00 Qd-feng wrote: link the /etc/localtime to time zone under usr/share/zoneinfo/ e.g. ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime Reply at: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395/comments/9 ------------------------------------------------------------------------ On 2016-05-17T12:26:29+00:00 Anat-mazurov wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395/comments/12 ------------------------------------------------------------------------ On 2016-05-17T13:16:21+00:00 Andreas Schwab wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395/comments/13 ------------------------------------------------------------------------ On 2023-01-11T19:17:04+00:00 Paul Eggert wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395/comments/19 ------------------------------------------------------------------------ On 2023-01-12T00:43:09+00:00 Guy Harris wrote: Most if not all of China and India are also now no longer on DST, which is why it happens with Asia/Shanghai. Reply at: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/868395/comments/20 ** Changed in: glibc Status: Unknown => Confirmed ** Changed in: glibc Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/868395 Title: localtime_r multiple times slower for Europe/Moscow timezone Status in GLibC: Confirmed Status in glibc package in Ubuntu: New Status in tzdata package in Ubuntu: Triaged Bug description: In version tzdata-2011j (tzdata-2011k also affected) was founded strange bug in russian timezones. Because of a law "On the Calculation of Time" there were changes in zone like: 3:00 Russia MSK/MSD 2011 changed to: 3:00 Russia MSK/MSD 2011 Mar 27 2:00s 4:00 - MSK But if no rule used for this change (using "-" instead of rule "Russia"), calling of system function localtime_r() takes more time (takes more than 40% time longer). I used following code for measuring: ============================== #include <time.h> #include <stdio.h> int main() { time_t t = time(0); int i; struct tm result; for(i=0; i < 10000000; i++) localtime_r(&t, &result); puts(ctime(&t)); return 0; } ============================== and also this sql code in mysql db: select benchmark(1000000, from_unixtime(1317044847)); For example, when I'm using new tzdata-2011j results are: 1. time ./a.out (c code) real 0m5.165s user 0m5.140s sys 0m0.000s 2. sql query mysql> select benchmark(1000000, from_unixtime(1317044847)); +-----------------------------------------------+ | benchmark(1000000, from_unixtime(1317044847)) | +-----------------------------------------------+ | 0 | +-----------------------------------------------+ 1 row in set (1.03 sec). And when I'm using old tzdata-2008b: 1. time ./a.out (c code) real 0m1.675s user 0m1.450s sys 0m0.000s 2. sql query mysql> select benchmark(1000000, from_unixtime(1317044847)); +-----------------------------------------------+ | benchmark(1000000, from_unixtime(1317044847)) | +-----------------------------------------------+ | 0 | +-----------------------------------------------+ 1 row in set (0.65 sec) This bug seemed critical on high loaded systems (for example, for databases that using unix timestamps). My configuration was: Description: Ubuntu 8.04.1 Release: 8.04 Packages: 2011j~repack-0ubuntu0.8.04 and 2008b-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/868395/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
