experiment with speeding up Time.local #13968

catlee · 2025-07-22T05:06:15Z

On macOS, methods like Time.local can be up to hundreds of times slower when run in a forked child process than when run in the parent process. This simple benchmark demonstrates the issue:

require "benchmark/ips"

def time_local
  Time.local(2025,7,21,14,23)
end

Benchmark.ips do |x|
  x.report("non-forked") { time_local }
  x.report("forked") do |times|
    pid = fork do
      times.times { time_local }
    end
    Process.wait(pid)
  end
  x.compare!
end

ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin20]
Warming up --------------------------------------
          non-forked     7.873k i/100ms
              forked   131.000 i/100ms
Calculating -------------------------------------
          non-forked     77.203k (± 1.0%) i/s   (12.95 μs/i) -    393.650k in   5.099458s
              forked      1.248k (± 2.1%) i/s  (801.54 μs/i) -      6.288k in   5.042401s

Comparison:
          non-forked:    77202.9 i/s
              forked:     1247.6 i/s - 61.88x  slower

This impacts all kinds of things from logging, parsing times, working with zipfiles with rubyzip, etc.

This PR implements a small cache for offsets from UTC for any given 15-minute quarters derived from the value passed to rb_localtime_r - this avoids multiple calls to libc's localtime_r for the same time values within the same 15-minute block of time. As far as I can tell there are no timezones past or present which have an offset that doesn't fall on a 15-minute boundary (e.g. +0/15/30/45 minutes).

The cache is cleared if the timezone is changed.

nobu · 2025-07-22T08:38:06Z

That benchmark looks including fork and waitpid times and doesn't feel fair enough.

Rather, I feel that this problem should be reported to Apple.
Might be intentional since fork is declared as deprecated, though.

#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>

void
localtime_benchmark(const char *cond)
{
    struct timespec ts, te;
    clock_gettime(CLOCK_MONOTONIC , &ts);
    for (long n = 0; n < 10000; ++n) {
        time_t lt = 1753075380;
        struct tm t;
        localtime_r(&lt, &t);
    }
    clock_gettime(CLOCK_MONOTONIC , &te);
    time_t diff = te.tv_sec - ts.tv_sec;
    unsigned long ndiff = te.tv_nsec;
    if (te.tv_nsec < ts.tv_nsec) {
        --diff;
        ndiff += 1000000000UL;
    }
    ndiff -= ts.tv_nsec;
    printf("%s: %ld.%.9lu\n", cond, diff, ndiff);
}

int
main(void)
{
    localtime_benchmark("non-forked");
    pid_t forked = fork();
    if (forked) {
        int stat;
        waitpid(forked, &stat, 0);
    }
    else {
        localtime_benchmark("    forked");
    }
    return 0;
}

non-forked: 0.001993000
    forked: 2.986874000

time.c

catlee · 2025-07-22T13:27:22Z

Rather, I feel that this problem should be reported to Apple.

Indeed. I did some searching around and found a few references which make me think this won't be fixed:

https://developer.apple.com/forums/thread/747499
https://developer.apple.com/forums/thread/737464?answerId=764686022#764686022
https://stackoverflow.com/questions/27932330/why-is-tzset-a-lot-slower-after-forking-on-mac-os-x

And from fork's manpage:

CAVEATS
There are limits to what you can do in the child process. To be totally safe you should restrict yourself to only executing async-signal
safe operations until such time as one of the exec functions is called. All APIs, including global data symbols, in any framework or library
should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frame-
works in the child process, you must exec. In this situation it is reasonable to exec yourself.

AIUI there is IPC signaling in place to notify processes of timezone changes, and these don't work after fork() before exec().

time.c

nobu · 2025-07-24T01:34:20Z

time.c

@@ -703,6 +704,11 @@ static struct vtm *localtimew(wideval_t timew, struct vtm *result);

 static int leap_year_p(long y);
 #define leap_year_v_p(y) leap_year_p(NUM2LONG(modv((y), INT2FIX(400))))
+static int calc_tm_yday(long tm_year, int tm_mon, int tm_mday);
+


Suggested change

static int calc_wday(int year_mod400, int month, int day);

time.c

nobu · 2025-07-24T01:41:54Z

time.c

+/* Cache key: 15-minute precision */
+typedef struct {
+    int year;
+    int month;
+    int day;
+    int hour;
+    int quarter;  /* 0-3 representing 00, 15, 30, 45 minute intervals */
+} offset_cache_key;


I guess it would be possible to pack the cache keys, so that the validness can be checked atomically.

Great idea. I think now we can probably just use our time_t value/15 for our cache key?

I haven't quite convinced myself that it's safe to use 15 minute quarters to cache by..... There are some historical timezones with odd offsets. I don't know of any yet where a dst boundary doesn't happen on a 15 minute boundary in UTC time though.

Perhaps modern time zones do not have such odd UTC offsets, but "zdump(1)" refers to "Europe/Astrahan".

$ LC_TIME=C /bin/date -z Europe/Astrakhan -j {-f,+}%Y-%m-%dT%H:%M:%S%Z 1924-04-30T00:00:00GMT 1924-04-30T03:12:12LMT

I think it'd be OK to abandon such cases, i.e., do not cache if the gmtoff % (15 * 60) != 0.

I don't think we can use value/15 in general.

E.g. in Newfoundland up until 2011, the daylight savings time change happened at 12:01:00, which is within the same 15-minute chunk of time as 12:00:00 or 12:02:00.

I do think a minute-based cache is generally safe.

nobu · 2025-07-26T11:06:22Z

configure.ac

+AC_ARG_ENABLE(macos-localtime-cache,
+	AS_HELP_STRING([--enable-macos-localtime-cache],
+		       [enable localtime cache optimization for macOS to improve forked process performance]),
+	[macos_localtime_cache=$enableval], [macos_localtime_cache=no])
+AS_IF([test "$macos_localtime_cache" = yes], [
+    AS_CASE(["$target_os"],
+        [darwin*], [
+            AC_DEFINE(ENABLE_MACOS_LOCALTIME_CACHE, 1, [Enable macOS localtime cache optimization])
+            AC_MSG_NOTICE([macOS localtime cache optimization enabled])
+        ],
+        [AC_MSG_WARN([--enable-macos-localtime-cache is only supported on macOS, ignoring])]
+    )
+])


This may not be limited to macOS in the future.
And do you have any reason not to enable it on macOS by the default?

Suggested change

AC_ARG_ENABLE(macos-localtime-cache,

AS_HELP_STRING([--enable-macos-localtime-cache],

[enable localtime cache optimization for macOS to improve forked process performance]),

[macos_localtime_cache=$enableval], [macos_localtime_cache=no])

AS_IF([test "$macos_localtime_cache" = yes], [

AS_CASE(["$target_os"],

[darwin*], [

AC_DEFINE(ENABLE_MACOS_LOCALTIME_CACHE, 1, [Enable macOS localtime cache optimization])

AC_MSG_NOTICE([macOS localtime cache optimization enabled])

],

[AC_MSG_WARN([--enable-macos-localtime-cache is only supported on macOS, ignoring])]

)

])

AC_ARG_ENABLE(localtime-cache,

AS_HELP_STRING([--enable-localtime-cache],

[enable localtime cache optimization to improve forked process performance]),

[localtime_cache=$enableval],

[AS_CASE(["$target_os"], [darwin*], [localtime_cache=yes], [localtime_cache=no])])

AS_IF([test "$localtime_cache" = yes], [

AC_DEFINE(ENABLE_LOCALTIME_CACHE, 1, [Enable localtime cache optimization])

AC_MSG_NOTICE([localtime cache optimization enabled])

])

I checked on Linux and it doesn't seem to have the same performance problem running localtime in a forked process.

catlee force-pushed the catlee/time_local branch 3 times, most recently from e2066b2 to e8595b9 Compare July 22, 2025 06:02

nobu reviewed Jul 22, 2025

View reviewed changes

time.c Outdated Show resolved Hide resolved

nobu reviewed Jul 24, 2025

View reviewed changes

time.c Outdated Show resolved Hide resolved

nobu reviewed Jul 25, 2025

View reviewed changes

nobu reviewed Jul 26, 2025

View reviewed changes

catlee added 6 commits July 30, 2025 17:24

experiment with speeding up Time.local

3b3a895

implement offset based cache

21387f9

Reuse existing logic for wday/leap year calculations

9b31ee6

implement cache per quarter (15-minutes)

5981220

remove redundant function

81fd0d5

implement 1 minute caching

c026384

catlee force-pushed the catlee/time_local branch from 29ec151 to c026384 Compare July 30, 2025 21:24

catlee marked this pull request as ready for review July 31, 2025 16:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

experiment with speeding up Time.local #13968

experiment with speeding up Time.local #13968

catlee commented Jul 22, 2025 •

edited

Loading

Uh oh!

nobu commented Jul 22, 2025 •

edited

Loading

Uh oh!

Uh oh!

catlee commented Jul 22, 2025

Uh oh!

Uh oh!

nobu Jul 24, 2025

Uh oh!

Uh oh!

nobu Jul 24, 2025

Uh oh!

catlee Jul 25, 2025

Uh oh!

nobu Jul 26, 2025

Uh oh!

nobu Jul 26, 2025

Uh oh!

catlee Jul 30, 2025 •

edited

Loading

Uh oh!

nobu Jul 26, 2025

Uh oh!

catlee Jul 30, 2025

Uh oh!

Uh oh!

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

experiment with speeding up Time.local #13968

Are you sure you want to change the base?

experiment with speeding up Time.local #13968

Conversation

catlee commented Jul 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nobu commented Jul 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

catlee commented Jul 22, 2025

Uh oh!

Uh oh!

nobu Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nobu Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

catlee Jul 25, 2025

Choose a reason for hiding this comment

Uh oh!

nobu Jul 26, 2025

Choose a reason for hiding this comment

Uh oh!

nobu Jul 26, 2025

Choose a reason for hiding this comment

Uh oh!

catlee Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nobu Jul 26, 2025

Choose a reason for hiding this comment

Uh oh!

catlee Jul 30, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

catlee commented Jul 22, 2025 •

edited

Loading

nobu commented Jul 22, 2025 •

edited

Loading

catlee Jul 30, 2025 •

edited

Loading