Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve mktime cache #101

Merged
merged 2 commits into from
May 22, 2024
Merged

Improve mktime cache #101

merged 2 commits into from
May 22, 2024

Conversation

bazsi
Copy link
Member

@bazsi bazsi commented May 17, 2024

This improves the caching in cached_mktime() so that a single real mktime() invocation is valid for up to an hour.

bazsi added 2 commits May 22, 2024 12:30
…t present

If the timestamp is not actually there in the message, we still tried
to call convert_and_normalize_wall_clock_time_to_unix_time_with_tz_hint(),
which in turn calls mktime(), which is a heavyweight operation.

Let's not do that.

Signed-off-by: Balazs Scheidler <[email protected]>
Without this patch, cached_mktime() produces a cached value for
every second, and would call mktime() again as the second changes.

This can be problematic when timestamps are parsed from different
seconds in succession (e.g. when the syslog timestamp is 1 second away
from a timestamp being parsed using strptime or date-parser).

In these cases the cache was invalidated and mktime() was called again.

mktime() is _slow_ as it even calls tzset() and validates that
/etc/localtime is still pointing to the same timezone.

This patch changes the caching strategy:
 - instead of specific seconds we calculate the cached value for the
   top of the hour (e.g. minutes==seconds==0)
 - timezones never change within the same hour, so as long as we are
   trying to use the cached value, we will do so as long as the
   year/month/day/hour value matches (plus isdst)
 - with this, mktime() will be called once every hour.

If there's some fluctuation between subsequent timestamps at the turn of the
hour, we can still exhibit limited caching (e.g. subsequent timestamps
from the last hour and this one), but this is a lot better than the
existing behaviour where we do that for every second.

Signed-off-by: Balazs Scheidler <[email protected]>
@alltilla alltilla merged commit 56b42e0 into axoflow:main May 22, 2024
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants