[Bug 868395] Re: localtime_r multiple times slower for Europe/Moscow timezone
Bug Watch Updater
868395 at bugs.launchpad.net
Thu Jan 12 07:58:53 UTC 2023
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
Foundations Bugs, 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
More information about the foundations-bugs
mailing list