refactor: replace MersenneTwister implementation with a pure-rand based one one #3288
+173
−326
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.
This PR replaces our
MersenneTwister
implementation with one modified from https://github.com/dubzzz/pure-rand.This PR does not change the underlying algorithm/results per seed.
Reasons for the change
Improved Performance
(higher is better)
Fastest is
new (32bit)
with 4.25 times the speed of faker's old implementation.This especially improves the performance for our - current default - 53 bit variant with a speed up by 5.65 times.
One of the main reasons for the speed up is that
pure-rand
's implementation uses existingMath
functions intended to work withint32
instead of manually clamping the values to the 32bit bounds after each operation. Since the new implementation is based on that, we also get these improvements.Why not use
pure-rand
as a dependencyinitByArray
method and I was unable to find that in the official spec to verify that it is compliant. @dubzzz feel free to use our new implementation of that method for your library.initByArray
method and maybe laterinitByString
/initByAny
that depend on itprivate static member functions
are up to 75% slower when compiled with target ESNext in comparison tostandalone functions
for some reason. It is the other way round when compiled with ES3/5 (used by pure-rand).@dubzzz We already tried to contact you via e-mail to check whether you are fine with our plans to use your implementation as a base for ours. Please let us know what you think.
The code remains MIT licensed, we just wanted to make sure you aren't blindsided by this change.