Skip to content

check for timegm() function to avoid slow fallback implementation#705

Merged
lauft merged 1 commit into
GothenburgBitFactory:developfrom
smemsh:cmake-timegm-propagate
Aug 27, 2025
Merged

check for timegm() function to avoid slow fallback implementation#705
lauft merged 1 commit into
GothenburgBitFactory:developfrom
smemsh:cmake-timegm-propagate

Conversation

@smemsh

@smemsh smemsh commented Aug 27, 2025

Copy link
Copy Markdown
Contributor

Libshared pulled in a fallback timegm() implementation in GothenburgBitFactory/libshared#99 that's quite slow and caused an unintentional performance regression in timewarrior, as documented in #703.

The fix is to have cmake test for system timegm() and set the proper define so the code won't build the fallback version, but rather use the system one.

This patch brings in the libshared change from GothenburgBitFactory/libshared#105 that reads the cmake header, and then also adds the check+define in CMakeLists.txt so that the generated cmake.h that Datetime will now see (from libshared change) includes the right #define to avoid the slow fallback.

Fixes #703

…ke.h

This fix will cause cmake to detect and define HAVE_TIMEGM in cmake.h if
the system libc has a timegm() function, and updates the libshared peg
to incorporate cmake.h in the included libshared build.  This way, the
slow Datetime::timegm() implementation is not used, but rather the fast
one in libc.  This fast one depends on HAVE_TIMEGM being defined by the
function in libshared's Datetime.cpp.

Fixes GothenburgBitFactory#703 which was a significant performance regression in 1.9.0
release.

Signed-off-by: Scott Mcdermott <scott@smemsh.net>
@lauft lauft modified the milestones: Next Release, 1.9.0 Aug 27, 2025
@lauft lauft merged commit efcbcbe into GothenburgBitFactory:develop Aug 27, 2025
16 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.

significant performance regression in 1.9.0 DOM access

2 participants