Latest Benchmarks

Browse the latest JavaScript performance benchmarks created by the community.

12123Test

No description provided

TextDecoder 'ascii' vs String.fromCharCodea

No description provided

Set vs Object vs Map (has/in)

Compare the speed to retrieve a value from three data structures that can be used for boolean referencing; i.e. for mapping enabled settings.

startsWith 1234

No description provided

parseInt vs Number BigInts

No description provided

Strip svg tags

No description provided

test DomParser vs Regex vs IndexIf

No description provided

Lodash Intersection with Arrays vs. native with sets vs. native filter with arrays

No description provided

URL parsing and matching

No description provided

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

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

Compare contains vs closest v2

No description provided

Classnames vs CLSX vs Alternatives vs custom

Compare CLSX vs Classnames vs an own implementation of creating a template string

parseInt vs Number(val.toFixed(0))

flatMap vs filter map

Compare contains vs closest

No description provided

flatMap() vs map(...).flat()

flatMap vs map and then flat()

Javascript: Case insensitive exact string comparison

No description provided

Regex /i vs .indexOf with tolowerCase once

Testing some things

Array.prototype.concat vs spread operator vs flat v2

Compare the new ES6 spread operator with the traditional concat() method

Split string vs Split regex perfs

No description provided

min func vs inline min

No description provided

async vs asyncPromiseAll - LinkedIn

A common LinkedIn post debunked by Andrea Marchetti

async vs asyncPromiseAll

A common LinkedIn post debunked by Andrea Marchetti

clamp vs bitClamp vs vs min vs bitMin

No description provided

clamp vs bitClamp

No description provided