5 ms·

> Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects? No,not really. I mean, in healthy projects build times

> Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects? No,not really. I mean, in healthy projects build times are dwarfed by the time it takes to run tests. In web development projects even the delivery and deployment steps dwarf build times.

dmm 6y ago
> in healthy projects build times are dwarfed by the time it takes to run tests I don't doubt that's often true but many Rust projects may be outliers here. A full, non-incremental build of a Rust project involves building all of its dependencies. This can add significant amounts of time if a project uses a big framework like Actix-web, which adds many dependencies. My tests however run very quickly, ~1ms each. So running thousands of tests only takes a few seconds, even on relatively slow gitlab runners.
- oehtXRwMkIs 6y ago
  Plus Rust by design avoids all sorts of bugs leading to less tests imo. Python for example you really want a lot of testing, maybe even contracts, but with Rust I find that many of those tests are irrelevant.
  - rumanator 6y ago
    > Plus Rust by design avoids all sorts of bugs leading to less tests imo. This assertion on the amount to tests makes no sense at all. Tests are not about language features. Tests are about checking invariantes, checking input and output bounds, and checking behavior. Tests focus on the interface, not the implementation. Tests only work if test coverage is high.
    - IshKebab 6y ago
      It makes total sense. Rust statically enforces many things you'd have to explicitly test for in other languages, for example types. So you don't need to write as many tests.
- kevincox 6y ago
  You should be caching the builds of your dependencies. This is very easy with cargo and GitLab. I think encouraging people to optimize this is a reasonable cost to push onto the free users.
  - papaf 6y ago
    To add to your point, the caching is done by adding a cache entry to .gitlab-ci.yml : variables: CARGO_HOME: $CI_PROJECT_DIR/cargo cache: key: "$CI_JOB_NAME" untracked: true paths: - cargo/ - target/
- snovv_crash 6y ago
  Is there an equivalent of `ccache` for Rust? For C++ it's been a total lifesaver, I've introduced it in multiple organizations for massively reducing (average) build times, even by sharing the cache on an NFS drive between multiple machines.
  - Camas 6y ago
    https://github.com/mozilla/sccache https://github.com/mozilla/sccache
    - IshKebab 6y ago
      Note the caveats though. In particular it can't cache Serde, which is easily the slowest popular crate to compile. Also the heavy use of static dispatch and LTO in Rust means a lot of the actually compilation happens in the final crate which is usually the one you modified. It definitely helps but not as much as in C++.
jamesh-gl 6y ago
GitLab Product Manager here - We’re working on ways to run fewer tests OR only the necessary tests earlier in a pipeline so you get to a result in fewer minutes. The first project towards this in the product is https://docs.gitlab.com/ee/user/project/merge_requests/fail_fast_testing.html https://docs.gitlab.com/ee/user/project/merge_requests/fail_... which we hope to bring down to the Core tier soon. -James H, GL Product Manager, Verify:Testing
- karlerss 6y ago
  I think most test runners have a --stop-on-failure feature, but using it has the downside of not giving you the complete list of failing tests. If you haven't touched your gitlab pipelines for a few months, check out DAG pipelines [0] - I got my web project deployment pipeline down from 25 to ~12 minutes by running tests sooner. [0] https://docs.gitlab.com/ee/ci/directed_acyclic_graph/ https://docs.gitlab.com/ee/ci/directed_acyclic_graph/

dmm 6y ago

> in healthy projects build times are dwarfed by the time it takes to run tests I don't doubt that's often true but many Rust projects may be outliers here. A full, non-incremental build of a Rust project involves building all of its dependencies. This can add significant amounts of time if a project uses a big framework like Actix-web, which adds many dependencies. My tests however run very quickly, ~1ms each. So running thousands of tests only takes a few seconds, even on relatively slow gitlab runners.

oehtXRwMkIs 6y ago
Plus Rust by design avoids all sorts of bugs leading to less tests imo. Python for example you really want a lot of testing, maybe even contracts, but with Rust I find that many of those tests are irrelevant.
- rumanator 6y ago
  > Plus Rust by design avoids all sorts of bugs leading to less tests imo. This assertion on the amount to tests makes no sense at all. Tests are not about language features. Tests are about checking invariantes, checking input and output bounds, and checking behavior. Tests focus on the interface, not the implementation. Tests only work if test coverage is high.
  - IshKebab 6y ago
    It makes total sense. Rust statically enforces many things you'd have to explicitly test for in other languages, for example types. So you don't need to write as many tests.
kevincox 6y ago
You should be caching the builds of your dependencies. This is very easy with cargo and GitLab. I think encouraging people to optimize this is a reasonable cost to push onto the free users.
- papaf 6y ago
  To add to your point, the caching is done by adding a cache entry to .gitlab-ci.yml : variables: CARGO_HOME: $CI_PROJECT_DIR/cargo cache: key: "$CI_JOB_NAME" untracked: true paths: - cargo/ - target/
snovv_crash 6y ago
Is there an equivalent of `ccache` for Rust? For C++ it's been a total lifesaver, I've introduced it in multiple organizations for massively reducing (average) build times, even by sharing the cache on an NFS drive between multiple machines.
- Camas 6y ago
  https://github.com/mozilla/sccache https://github.com/mozilla/sccache
  - IshKebab 6y ago
    Note the caveats though. In particular it can't cache Serde, which is easily the slowest popular crate to compile. Also the heavy use of static dispatch and LTO in Rust means a lot of the actually compilation happens in the final crate which is usually the one you modified. It definitely helps but not as much as in C++.

jamesh-gl 6y ago

GitLab Product Manager here - We’re working on ways to run fewer tests OR only the necessary tests earlier in a pipeline so you get to a result in fewer minutes. The first project towards this in the product is https://docs.gitlab.com/ee/user/project/merge_requests/fail_fast_testing.html https://docs.gitlab.com/ee/user/project/merge_requests/fail_... which we hope to bring down to the Core tier soon. -James H, GL Product Manager, Verify:Testing

karlerss 6y ago
I think most test runners have a --stop-on-failure feature, but using it has the downside of not giving you the complete list of failing tests. If you haven't touched your gitlab pipelines for a few months, check out DAG pipelines [0] - I got my web project deployment pipeline down from 25 to ~12 minutes by running tests sooner. [0] https://docs.gitlab.com/ee/ci/directed_acyclic_graph/ https://docs.gitlab.com/ee/ci/directed_acyclic_graph/