| Benchmark name | When Created |
|---|---|
| startsWith 1234 | one year ago |
| parseInt vs Number BigInts | one year ago |
| Strip svg tags | one year ago |
| test DomParser vs Regex vs IndexIf | one year ago |
| Lodash Intersection with Arrays vs. native with sets vs. native filter with arrays | one year ago |
| URL parsing and matching | one year ago |
|
Array.filter vs. raw for-loop vs. for..of vs. Array.reduce vs. generator spread 2
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 |
one year ago |
|
Array.filter vs. raw for-loop vs. for..of vs. Array.reduce vs. generator spread
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 |
one year ago |
| Compare contains vs closest v2 | one year ago |
|
Classnames vs CLSX vs Alternatives vs custom
Compare CLSX vs Classnames vs an own implementation of creating a template string |
one year ago |
|
parseInt vs Number(val.toFixed(0))
flatMap vs filter map |
one year ago |
| Compare contains vs closest | one year ago |
|
flatMap() vs map(...).flat()
flatMap vs map and then flat() |
one year ago |
| Javascript: Case insensitive exact string comparison | one year ago |
|
Regex /i vs .indexOf with tolowerCase once
Testing some things |
one year ago |
|
Array.prototype.concat vs spread operator vs flat v2
Compare the new ES6 spread operator with the traditional concat() method |
one year ago |
| Split string vs Split regex perfs | one year ago |
| min func vs inline min | one year ago |
|
async vs asyncPromiseAll - LinkedIn
A common LinkedIn post debunked by Andrea Marchetti |
one year ago |
|
async vs asyncPromiseAll
A common LinkedIn post debunked by Andrea Marchetti |
one year ago |
| clamp vs bitClamp vs vs min vs bitMin | one year ago |
| clamp vs bitClamp | one year ago |
| RegEx.exec vs String.match2 | one year ago |
| FlatMap vs concatenation | one year ago |
| array.length vs array.length > 0 vs !!array.length | one year ago |
