-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto: add buffering to randomInt #35110
Conversation
Review requested:
|
I'm decidedly 'meh' on this. No one's been complaining about its speed so far. |
@bnoordhuis How about adding this for the sync case only? That's a relatively small change with a big payoff, and I think the performance of the sync case is more critical anyway. The downside is that this approach results in the existing code duplication between sync and async behavior, which essentially implements the entire thing twice. |
@nodejs/crypto can you review this please? Those benchmark results look very good! |
const randomCache = new FastBuffer(3072); | ||
let randomCacheOffset = randomCache.length; | ||
let asyncCacheFillInProgress = false; | ||
const asyncCachePendingTasks = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using an array for this is usually not performing as expected for high numbers. Using a linked list solves this problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have fixed-queue
which also might be appropriate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might make sense to introduce a random buffer internal utility that can be used in multiple places (here, the randomuuid fn, etc). That can be done later tho
@mcollina I doubled the cache size, but a more efficient way to improve performance might be to reduce the number of bytes that is used for each random integer. In most cases, we don't actually need 6 bytes, probably ony 2 to 4 bytes. (It depends on the use case, of course.) |
@tniessen could you resolve conflicts on this one? |
efd2b91
to
499bed1
Compare
Benchmark results still look good: Table
Unformatted output
|
let randomCacheOffset = randomCache.length; | ||
let asyncCacheFillInProgress = false; | ||
const asyncCachePendingTasks = []; | ||
|
||
// Generates an integer in [min, max) range where min is inclusive and max is | ||
// exclusive. | ||
function randomInt(min, max, callback) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An idea for potential enhancement: consider adding options arg with disableEntropyCache
setting to allow disabling the random cache. This way will make the API consistent with randomUUID
(see #36729).
@@ -179,6 +179,13 @@ function randomFill(buf, offset, size, callback) { | |||
// e.g.: Buffer.from("ff".repeat(6), "hex").readUIntBE(0, 6); | |||
const RAND_MAX = 0xFFFF_FFFF_FFFF; | |||
|
|||
// Cache random data to use in randomInt. The cache size must be evenly | |||
// divisible by 6 because each attempt to obtain a random int uses 6 bytes. | |||
const randomCache = new FastBuffer(6 * 1024); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider using secureBuffer
here to integrate with secure heap (see randomUUID
's random cache and #36779).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion. We could do that, but UUIDs and random ints always result in insecure memory allocations anyway that mostly destroy any security guarantees. JavaScript is terrible for secure memory management.
@mcollina ... please take another look |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
499bed1
to
fe80c8e
Compare
fe80c8e
to
2cdb569
Compare
I believe this was technically ready to land a while ago, but I just addressed @aduh95's comments regarding primordials. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Benchmark results still look good: Unformatted output
|
PR-URL: #35110 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Andrey Pechkurov <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
Landed in 5dae7d6, thanks for reviewing. |
PR-URL: #35110 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Andrey Pechkurov <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
PR-URL: #35110 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Andrey Pechkurov <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
This adds a buffer to
randomInt
to prevent callingrandomBytes
on each invocation. It also simplifies the actual calculation to always be synchronous, and doesn't duplicate the logic for asynchronous behavior. However, this change does include additional code to manage the cache.Performance is improved significantly, by large factors, for synchronous calls and sequential asynchronous calls. For parallel calls, performance is about the same when requesting a few hundred random integers at a time.
Performance is significantly worse when requesting a large number of random integers asynchronously and in parallel. The reason is that this implementation delays all requests until the buffer has been refilled with random data, then serves as many requests as it can, then delays the remaining requests until the buffer has been refilled again, and so on. With a buffer size of 3KiB, 500 random integers can be provided without having to call
randomBytes
. When the benchmark requests 100,000 random integers asynchronously and in parallel, instead of processing 100,000 calls torandomBytes
in parallel, the buffered implementation provides 200 batches of 500 numbers each sequentially.randomInt
with a callback slow, but would make generating huge amounts of random integers at the same time faster.Benchmark results based on 30 runs (3988798 compared to the master branch at b5a47ca):
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes