-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Main.yml: Move very long job from debug to release with -DDEBUG
and FORCE_ASSERT
#18081
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
Conversation
Currently, on each PR iteration: 2* (15 minutes building + 1h45' testing) Moving from debug to reldebug: 2* (18 minutes building + 2' testing) Moving from 2 parallel jobs to a single one: 18 minutes building + 4' testing Considering building step might also be cached, this is 10x to 20x improvement (in this particular step, that was the more time consuming at the moment).
175e08e
to
ca917f0
Compare
Thanks - but we run Perhaps it makes more sense to revisit some of those checks to speed up debug builds. |
I see, right, thanks! Maybe it's as simple as adding -DDEBUG define a release compilation mode? I do see now we want to run the I will check if that works. |
Checks are performed (tested adding a static_assert(0) that was ignored in |
We should also run asserts then, right? Or does |
I think debug does enable asserts already, but I will check with a bogus I stopped after a while, but using the timing from CI where it's 2 minutes vs 100 minutes, I would say some form of release build + |
Assertion do trigger when |
I think we're good then - I can't think of any reason not to make the switch |
Actually hold on - we're not running sanitizers in this mode, right? Maybe that accounts for the difference. |
Maybe we look at this with some more care, iterating over CMake and checking stuff, maybe we need to bring in sanitizers and possibly other stuff, then the proper way it's not a single hack but refactoring CMake (so But I think basically between running with |
ca1add8
to
ee628ce
Compare
22e99c7
to
e6efc1d
Compare
@Mytherin: updated PR message and approach, I think this should do what we want. |
-DDEBUG
and FORCE_ASSERT
e6efc1d
to
905e470
Compare
905e470
to
3134493
Compare
Thanks! |
fix statistics propagation for anti-joins on empty tables (duckdb/duckdb#17439) Run Python workflow against both Python 3.9 and 3.13 on PR to ensure … (duckdb/duckdb#18080) Main.yml: Move very long job from debug to release with `-DDEBUG` and `FORCE_ASSERT` (duckdb/duckdb#18081)
fix statistics propagation for anti-joins on empty tables (duckdb/duckdb#17439) Run Python workflow against both Python 3.9 and 3.13 on PR to ensure … (duckdb/duckdb#18080) Main.yml: Move very long job from debug to release with `-DDEBUG` and `FORCE_ASSERT` (duckdb/duckdb#18081) Co-authored-by: krlmlr <krlmlr@users.noreply.github.com>
Currently we run the standard test suite in
debug
mode, with the aim of testing slow verifiers masked by#ifdef DEBUG
, enabling D_ASSERT, and running additional sanitizers.This works, but has a drawback that compiling for
debug
is tied to-O0
, that is no optimizations performed.Proposal here is to run this particular step in
release
mode, while:-DDEBUG
, so that slow verifiers masked by#ifdef DEBUG
are still includedrelassert
mode)FORCE_ASSERT
CMake flagChanges as done here are local to the workflow, but we could consider adding another compilation mode, since this might be of general usage.
Currently, on each PR iteration: 2* (15 minutes building + 1h45' testing)
Moving to release +
-DDEBUG -DFORCE_ASSERT
: 20 minutes building + 25 minutes testingBuild step might also be cached, this is 10x improvement for this step, that is at the moment the most expensive one run on every PR.