Benchmarks I've written during development both professionally and during Open Source contributions.
  • TypeScript 99.6%
  • JavaScript 0.4%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Seth Falco a3479057e4
All checks were successful
ci/woodpecker/manual/ci Pipeline was successful
chore(ci): add editorconfig-checker to CI
2026-11-10 23:53:17 +00:00
.woodpecker chore(ci): add editorconfig-checker to CI 2026-11-10 23:53:17 +00:00
src chore: adopt TypeScript 💪(•ᴗ•💪) 2026-11-10 00:29:48 +00:00
.editorconfig chore: adopt TypeScript 💪(•ᴗ•💪) 2026-11-10 00:29:48 +00:00
.gitignore ci: add test and lint tasks 2025-05-23 22:18:03 +01:00
.yarnrc.yml chore: use eslint-config package from npmjs.com 2026-03-04 21:21:26 +00:00
eslint.config.mjs chore: migrates to @sethfalco/eslint-config package 2026-02-22 20:17:01 +00:00
LICENSE initial commit 2024-07-01 17:30:31 +01:00
package.json chore: bump Node.js version in engines 2026-11-10 22:52:21 +00:00
README.md chore: adopt TypeScript 💪(•ᴗ•💪) 2026-11-10 00:29:48 +00:00
tsconfig.json chore: adopt TypeScript 💪(•ᴗ•💪) 2026-11-10 00:29:48 +00:00
yarn.lock chore: use eslint-config package from npmjs.com 2026-03-04 21:21:26 +00:00

Node.js Microbenchmarks

Benchmarks I've written during development both professionally and during Open Source contributions. The repository is for me to scaffold benchmarks quickly, and to refer back to benchmark results later.

While the repository is public, the purpose is to share decisions I've made. This is not a collaborative effort to publish and maintain benchmarks together. If you're able to pitch a better solution to a problem covered in the repository, feel free to share it! However, pull requests adding benchmarks for new problems won't be accepted.

Running Benchmarks

Install dependencies with:

yarn install

Then run the relevant benchmark with Node.js:

node src/benchmarks/is-char-whitespace.ts

Methodology

All tests cases are constructed similarly and use the same options.

For input, instead of testing single arguments, we test an array of arguments. This is so we can get what is generally most performant, rather than what is most performant for a specific scenario.

The data array may need to be tweaked depending on the data you expect to encounter in the real-world. For example, two solutions could be correct, but perform differently based on the input received. Sometimes the solution that's generally slower is better, because it performs faster for input you're expecting to encounter most of the time in production.

For most benchmarks, we enforce that all functions must have identical input/output. However, there are a few exceptions due to quirks like floating point precision. Cases like these will have warnings documented at the top of the file, and you'll need to strike a balance between performance and precision on a case-by-case basis.

I've written a similar repository for Java microbenchmarks: