briansmith
commented
7 years ago More ideas:
-
Deleting even more code, and making the code simpler yet. This is actually the primary way in which I intend to contribute to resolving this issue.
-
Switch from C++ to Rust for the tests in bn_test.cc. bn_test.cc is the last C++ test suite. Presumably the C++ compiler is much slower than the C compiler, so getting rid of the C++ code should make the build faster. Note that bn_test.cc forces the existence of most (all?) the C/C++ code in crypto/test, which is several files. Though, the added Rust code may make the build even slower.
-
Many of the "unit" tests in ring are probably better recast as "integration" tests. This involves moving them out from inline submodules in src/ to their own separate files in tests/. Presumably, when ring is built for the purpose of being used by a dependent crate, only the sources in src/ are compiled, not the tests; the tests should only be built if/when the user ever runs "cargo test -p ring". (If that is not the case, that's probably a performance bug in cargo that should be fixed.) This should non-trivially reduce the amount of Rust code that the Rust compiler sees during a typical compilation. Also, this is something we want to do anyway because it helps ensure that the public API is properly exported.
emberian
eddyb
In another bug, @luser suggested that we add a way to just build the digest API, without the rest, in the name of making the build faster: “Mostly faster compiling, yeah. Rust compilation is slow enough, pulling in another large dependency just to use one small bit of it makes the problem even worse.”
Since that time, the build system has been completely rewritten, mostly through @weiznich's awesome work. One thing we did was pregenerate the assembly language code from the PerlAsm scripts, so that all the Perl steps are skipped when building from crates.io, which may help.
But, we should still try to make the build faster. This requires somebody to profile the build to find out what the bottlenecks are.
Wild guess ideas:
While we did spend significant effort ensuring the build is parallelized, we didn't make everything perfect in that respect. There is probably some low-hanging fruit regarding parallelism there.
When we're not building from .Git (when ".git" doesn't exist), maybe we should just avoid dirty checking and just go straight to compiling everything unconditionally. Presumably, Cargo does its own dirty checking to ensure each library is only built once, so our own dirty checking is superfluous in that case as our build script would only be run when all files are dirty. (Dirty checking would still be essential for Git builds, of course.)
Now there is a ring-test library that contains some test code, which is built in addition to the ring-core library which contains the C & asm code for the library proper. The ring-test library ideally shouldn't even be linked into the ring library at all. If we changed constant_time_test and bn_test to be "integration" tests instead of "unit" tests then we could use
#[link]inside the integration test files to link libring-test.a only to the integration tests, and not to everything else. If this were done, then dependent crates that build ring from crates.io wouldn't need to link libring-test.a. Presumably, we would use the presence or absence of ".git" in build.rs to determine whether or not to build libring-test.a. However, I'm not sure that this is a good idea because users can do "cargo test -p ring" from within a dependent crate to run the ring test suite, and this would break. Probably we need to wait for https://github.com/rust-lang/cargo/issues/1581 instead.