Feature for disabling system randomness? about lipsum HOT 4 CLOSED

Hey Martin,

I would be happy with such a feature — I expect it will just be a few #[cfg(feature = "...")] lines sprinkled here and there :-) If it makes things more flexible for you and others, then I'm for it.

However, I wonder if you would see any actual improvement in binary size. I went through an exercise recently to measure the binary size in my Textwrap crate. See the binary-sizes example. If you clone Textwrap and do

$ cd examples/binary-sizes
$ cargo run --example make-table

then you see the size of an example program using different feature flags. I would suggest you write a similar tiny program and compile it with and without the dependencies (you don't need to do the whole table thing, we can always look at that later if we want).

My thesis is that it won't make a big difference: if you only call ..._from_seed functions, then the linker should strip out the dead code and you get a lean binary already. Especially when you use setting like lto = true when compiling.

from lipsum.

I ran a few of my own experiments. You are right, the impact on file size is negligible. However, another metric has turned out to be more interesting: compile time.

I ran four compiles of each of the configurations in the table with a clean target directory using time cargo build. The table reports the real (wall-clock) time.

(weirdly, release mode is faster here; the benchmarks were run on Debian Stretch, on WSL 2 in the mounted Windows file system, so disk I/O might be slow)

With the --no-default-features configuration, the features std, std_rng, and getrandom were omitted from rand. This reduces the number of total crates compiled from 8 to 5, dropping libc, getrandom, and cfg-if.

In theory, this would also enable a version of this crate that is no-std and instead just uses alloc but I don't really see a use case for that.

Do you think these compile time gains justify adding a new default feature? If yes, what do you think should be its name? (I called it getrandom but since it enables more than just that feature flag in rand it might not be especially apt)

from lipsum.

It think this feature would be nice to have because right now the library does not compile to WebAssembly. You can work around the error by adding getrandom as a direct dependency and enabling its "js" feature. But just disabling this library's randomness feature would be much nicer.

from lipsum.

Hey both, I'm sorry for not looking at this sooner! It had slipped my mind.

@reknih, thanks for actually testing it out! I'm personally not very upset about compile times in dependencies since I normally only compile them once per project. But I know that lots of people care about it :-)

@laurmaedje, thanks, I had no idea that it could not compile for WebAssembly! That's something I would love to fix!

@reknih, would you want to put up a PR with your changes? Then we can discuss names etc on that.

from lipsum.