我需要来自arc4random_buf的数十亿随机字节，我的策略是一次请求X个随机字节，并重复多次。
我的问题是X应该有多大。由于nbytes的arc4random_buf论证可以任意大，我想必须有某种内部循环，每次执行它时都会产生一些熵。比如说，如果X是每次迭代生成的随机字节数的倍数，性能可以提高，因为我不浪费任何熵。
我在macOS上，不幸的是封闭源代码，所以我不能简单地阅读源代码。有没有可行的方法来确定最佳X？
在典型的目标系统上做一些基准可能是解决这个问题的最佳方法，但是看看几个实现，缓冲区大小似乎不太可能对arc4random_buffer的成本产生很大影响。
原始实现将arc4random_buffer实现为围绕生成一个字节的函数的简单循环。只要缓冲区足够大以避免过多的呼叫开销，它应该没什么区别。
FreeBSD库实现似乎试图通过周期性地计算大约1K的随机字节来进行优化。然后arc4random_buffer使用memcpy将字节从内部缓冲区复制到用户缓冲区。
对于FreeBSD实现，最佳缓冲区大小将是内部缓冲区中可用的数据量，因为这样可以最大限度地减少对memcpy的调用次数。但是，没有办法知道它是多少，并且由于重新加密算法，它在每次调用时都不一样。
我的猜测是你会发现缓冲区大小比16K更小，甚至可能更小。对于FreeBSD实现，如果缓冲区大小是8的倍数，则效率会稍高一些。
附录：我所知道的所有实现都具有全局重定密钥阈值，因此您无法通过更改arc4random_buffer中的缓冲区大小来影响重新加密的成本。该库只是重新生成每个生成的X字节。