optimize curve25519 for tests #9606

Ekleog-NEAR · 2023-09-27T20:00:06Z

This brings down the runtime of tests involving the runtime-tester by 40%, ie. 7.5s -> 4.5s for the runtime quickcheck added in #9602. Hopefully other tests will also profit from it, though I haven’t benchmarked it all.

The overall runtime on buildkite of the cargo test nightly not integration-tests* test seems, on a sample of 1, to be roughly the same (+- 10s) before addition of the test from #9602, so there should not be a significant delay in CI round-trip due to it, and it should mostly impact local development that rarely sees changes from dependencies.

This brings down the runtime of tests involving the runtime-tester by 40%, ie. 7.5s -> 4.5s. Hopefully other tests will also profit from it, though I haven’t benchmarked it all.

wacban

Sorry for late review, I was off. For my education, what are the pros and cons of this approach? Will that make compilation slower and by how much? Are there any other targets that would benefit from it?
LGTM but I'm not familiar with this area. If there is anyone who'd be better suited for review please ask them.

This brings down the runtime of tests involving the runtime-tester by 40%, ie. 7.5s -> 4.5s for the runtime quickcheck added in #9602. Hopefully other tests will also profit from it, though I haven’t benchmarked it all. The overall runtime on buildkite of the `cargo test nightly not integration-tests*` test seems, on a sample of 1, to be roughly the same (+- 10s) before addition of the test from #9602, so there should not be a significant delay in CI round-trip due to it, and it should mostly impact local development that rarely sees changes from dependencies.

Ekleog-NEAR · 2023-10-12T18:51:25Z

what are the pros and cons of this approach? Will that make compilation slower and by how much?

The pro is basically tests run faster. The con is that whenever the dependency changes, we need to optimize it, and so the rebuilds take more time.

Usually for dependencies that are not on a hot path, the added compilation time is not worth the test speedup. However, as soon as a dependency takes a significant amount of time, optimizing it can significantly improve on the compile-and-test cycle speed, especially because we most often compile-and-test much more often than we actually bump dependencies.

However, CI is usually mostly unaffected by these changes, because it needs to rebuild the whole thing each time, and so needs to pay the compilation cost each time. However, for the hottest-path dependencies, it can still get faster. This is not the case in this PR, as buildkite showed basically no changes in the overall time taken to build.

Are there any other targets that would benefit from it?

I’m currently investigating this, just opened #9671 and am looking at a few other promising targets. However, this very much depends on which places we usually compile-and-test, and I’m checking mostly the full test suite, integration-tests and a few crates that seemed big to me.

So if you often run some specific test suite and find it slow, it’s probably worth running samply on it once and looking at whether there’s an obvious dependency that could be optimized to make your command faster, as the cost of optimizing a single dependency is usually not that big :)

The runtime of the whole test suite gets down by ~2.5% with this change. Integration tests get a similar speedup. CI times will be confirmed to not have too much change by it running on this PR. See also near#9606.

The runtime of the whole test suite gets down by ~2.5% with this change. Integration tests and near-vm-runner get a ~3.5% speedup. CI times will be confirmed to not have too much change by it running on this PR. See also near#9606.

The runtime of the whole test suite gets down by ~2.5% with this change. Integration tests get a similar speedup. CI times will be confirmed to not have too much change by it running on this PR. See #9606.

The runtime of the whole test suite gets down by ~2% with this change. Integration tests and near-vm-runner also get a similar speedup. CI times will be confirmed to not have too much change by it running on this PR. See also near#9606.

The runtime of the whole test suite gets down by ~2.5% with this change. Integration tests get a similar speedup. CI times will be confirmed to not have too much change by it running on this PR. See also #9606.

The runtime of the whole test suite gets down by ~2% with this change. Integration tests and near-vm-runner also get a similar speedup. CI times will be confirmed to not have too much change by it running on this PR. See also #9606.