Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Make
UUIDGen
more performant #3647Make
UUIDGen
more performant #3647Changes from 21 commits
dbd35db
22db811
2202a9f
cb28120
c7a167b
77d6081
6552d20
ab1573d
3d0d4c4
b0bf31c
47b3544
d906316
b611dda
1655b79
5a9259c
1c6b6ec
c4c6dc0
e98eb09
c2633ee
816d1c4
5519064
db8a428
201d8e0
4b4ded3
eead224
7764e24
31897c4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This suddenly introduces an implicit
Random[IO]
, which doesn't exist right now, and means thatSecureRandom
will end up being the de factoRandom
used in most situations. Is that what we want?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.
Oh, good catch, I totally missed this because of the inheritance relationship, and maybe this is what @durban was getting at in #3647 (comment).
Well, it's tricky. To be honest I'm not entirely sure if I see the harm, but these sorts of implicits have bitten us in the past. In fact,
UUIDGen
being an implicit is biting us already ...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.
I didn't think about this when I wrote that coment, but I agree that it could be a problem. Although, the worst problem I can think of right now is that the
SecureRandom
is probably slower than a non-secureRandom
, which is not the end of the world... but it is still not clear to me howRandom
is expected to be used: a user creates an instance themselves, then passes that instance implicitly?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.
Yeah it's not the end of the world. Much better to default to
SecureRandom
than the other way around lol ...See also:
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.
The other overload above (line 114) refers to this method. However, the behavior of the 2 are now quite different. I think the other overload could also benefit from the new improvements, although the
n: Int
does not make a lot of sense for the best case (nonblocking) PRNG.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.
Yes, for the best case
n: Int
. It will only sense in the worst case, when we fall back to a pool.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.
I wasn't very clear: I'm thinking about the fact that the method on line 116 is creating an rng which is "sharded", but calls (potentially) blocking code in
delay
. The latter is solved by this PR for the other overload. I think it should be solved for the overload in line 116 too.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.
Hmm, what's your suggestion for implementing method on line 116 with our new implementation of
javaSecuritySecureRandom
?