-
Notifications
You must be signed in to change notification settings - Fork 8
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
test/streaming.cc takes minutes to compile #275
Comments
From an offline discussion with @benh : a likely hypothesis is that the long eventuals chains in streaming.cc are indeed causing slow compilation times. One workaround he proposes is to split streaming.cc into many files (one file per test) so there's at most one long eventual per test (a similar thing was done for eventuals tests in #182 ). |
Compiling the output files generated by
|
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
Hmm, I'm no longer able to reproduce these multi-minute compile times. clang (3 runs):
gcc (3 runs):
I'm going to close this: 30s isn't great but it's tolerable. (I think that compiling code generated from |
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
@onelxj it sounds like you're working on the slow compile times of foo.eventuals.cc noted in #275 (comment) : nice!! |
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc. TESTED=added a clang-only change to `eventuals/just.h` and saw the build succeed on all platforms: https://github.com/3rdparty/eventuals/actions/runs/2598422120 Clang-only change was: ```c++ ```
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc. Make the `build_and_test` action run a clean before building so that output from one compiler isn't used in a build for a different compiler. This fixes the build errors reported in #324. TESTED=added a clang-only change to `eventuals/just.h` and saw the build succeed on all platforms: https://github.com/3rdparty/eventuals/actions/runs/2598422120 Clang-only change was: ```c++ \#ifndef __clang__ \#error "Must compile with clang" \#endif ``` Fixes #324. Fixes #331.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc. Make the `build_and_test` action run a clean before building so that output from one compiler isn't used in a build for a different compiler. This fixes the build errors reported in #324. TESTED=added a clang-only change to `eventuals/just.h` and saw the build succeed on all platforms: https://github.com/3rdparty/eventuals/actions/runs/2598422120 Clang-only change was: ```c++ \#ifndef __clang__ \#error "Must compile with clang" \#endif ``` Fixes #324. Fixes #331.
https://stackoverflow.com/a/67644572 makes me think that this error occurs when the compiler OOMs. So I think in addition to slow compilation time, complex eventuals structures are also hitting the compiler's memory limits. I'm optimistic that clang might also help here, but it does worry me that non-trivial eventuals use stretches C++ compilers to their limits: this might make the compilation experience pretty rough for a non-trivial codebase that makes heavy use of eventuals. (Notably, the above compilation error occurs when using |
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc. Make the `build_and_test` action run a clean before building so that output from one compiler isn't used in a build for a different compiler. This fixes the build errors reported in #324. TESTED=added a clang-only change to `eventuals/just.h` and saw the build succeed on all platforms: https://github.com/3rdparty/eventuals/actions/runs/2598422120 Clang-only change was: ```c++ \#ifndef __clang__ \#error "Must compile with clang" \#endif ``` Fixes #324. Fixes #331.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc. Remove the `--spawn_strategy=local` flag, allowing bazel to default to what I think is a `sandboxed` strategy (which is preferred above `local` in bazel's automatic strategy selection: https://blog.bazel.build/2019/06/19/list-strategy.html#after-bazel-0-27 ). This `spawn_strategy` change fixes the build errors reported in #324. TESTED=added a clang-only change to `eventuals/just.h` and saw the build succeed on all platforms: https://github.com/3rdparty/eventuals/actions/runs/2598422120 Clang-only change was: ```c++ \#ifndef __clang__ \#error "Must compile with clang" \#endif ``` Fixes #324.
This should speed up template compilation times and improve #275. This also ensures that clang is used on all platforms. Before this PR, our CI servers were building with gcc. Remove the `--spawn_strategy=local` flag, allowing bazel to default to what I think is a `sandboxed` strategy (which is preferred above `local` in bazel's automatic strategy selection: https://blog.bazel.build/2019/06/19/list-strategy.html#after-bazel-0-27 ). This `spawn_strategy` change fixes the build errors reported in #324. TESTED=added a clang-only change to `eventuals/just.h` and saw the build succeed on all platforms: https://github.com/3rdparty/eventuals/actions/runs/2598422120 Clang-only change was: ```c++ \#ifndef __clang__ \#error "Must compile with clang" \#endif ``` Fixes #324.
This file: https://github.com/3rdparty/eventuals-grpc/blob/main/test/streaming.cc
Takes several minutes to compile as part of this build:
Sample output from a not-yet-done bazel build with default compilation option (5 minutes and counting!):
My wild guess as to what's going on: we have some long eventual chains in this file. Does that result in slow compilation times due to heavy template nesting? If so, here's a resource on how to profile time spent in the compiler: stackoverflow.com/questions/15818281/profiling-template-metaprogram-compilation-time
It looks like we're building using GCC. I wonder if Clang's any faster?
(This issue is a recreated version of 3rdparty/eventuals-grpc#73 now that eventuals-grpc is a read-only repo)
The text was updated successfully, but these errors were encountered: