Browse the latest JavaScript performance benchmarks created by the community.
No description provided
No description provided
No description provided
No description provided
No description provided
No description provided
Compare the speed to retrieve a value from three data structures that can be used for boolean referencing; i.e. for mapping enabled settings.
No description provided
No description provided
No description provided
No description provided
Compare the speed to retrieve a value from three data structures that can be used for boolean referencing; i.e. for mapping enabled settings.
No description provided
No description provided
No description provided
No description provided
No description provided
No description provided
Changes in version 2: - Actually call predicate in generator function. Changes in this fork include (but might not be limited to): - Complete refactoring - Fixed memory leak - Even if you didn't run out of memory this still heavily affected performance, rendering the results basically useless. - Attempted to make test cases less likely to be optimized away (larger array, randomized values) - Changed for..in to for..of - One shouldn't use for..in for array access. It doesn't behave like other loops in that: 1. It returns all enumerable properties in the entire prototype chain. Usually not a problem, but if you're using inheritance it might. 2. It doesn't visit empty slots. So if you created a sized array (i.e. new Array(123)) and looped over it with for..in it would visit exactly 0 slots. 3. It returns indexes as strings. Could cause subtle bugs since it would work with abstract comparison operators more or less as though it was a number, but not so much with, for instance, the + operator. - Added Array.reduce test - Added generator test
Changes in this fork include (but might not be limited to): - Complete refactoring - Fixed memory leak - Even if you didn't run out of memory this still heavily affected performance, rendering the results basically useless. - Attempted to make test cases less likely to be optimized away (larger array, randomized values) - Changed for..in to for..of - One shouldn't use for..in for array access. It doesn't behave like other loops in that: 1. It returns all enumerable properties in the entire prototype chain. Usually not a problem, but if you're using inheritance it might. 2. It doesn't visit empty slots. So if you created a sized array (i.e. new Array(123)) and looped over it with for..in it would visit exactly 0 slots. 3. It returns indexes as strings. Could cause subtle bugs since it would work with abstract comparison operators more or less as though it was a number, but not so much with, for instance, the + operator. - Added Array.reduce test - Added generator test
No description provided
Compare CLSX vs Classnames vs an own implementation of creating a template string
flatMap vs filter map
No description provided
flatMap vs map and then flat()