anonrig / fast-querystring

A 45% faster alternative to node:querystring module

fast-querystring

Fast query-string parser and stringifier to replace the legacy node:querystring module.

Installation

npm i fast-querystring

Features

• Supports both parse and stringify methods from node:querystring module
• Parsed object does not have prototype methods
• Uses & separator as default
• Supports only input of type string
• Supports repeating keys in query string
  • foo=bar&foo=baz parses into {foo: ['bar', 'baz']}
• Supports pairs with missing values
  • foo=bar&hola parses into {foo: 'bar', hola: ''}
• Stringify does not support nested values (just like node:querystring)

Usage

const qs = require('fast-querystring')

// Parsing a querystring
console.log(qs.parse('hello=world&foo=bar&values=v1&values=v2'))
// {
//   hello: 'world',
//   foo: 'bar',
//   values: ['v1', 'v2']
// }

// Stringifying an object
console.log(qs.stringify({ foo: ['bar', 'baz'] }))
// 'foo=bar&foo=baz'

Benchmark

All benchmarks are run using Node.js v20.2.0 running on M1 Max.

• Parsing a query-string

> node benchmark/parse.mjs

╔═════════════════════════════════════════╤═════════╤═══════════════════╤═══════════╗
║ Slower tests                            │ Samples │            Result │ Tolerance ║
╟─────────────────────────────────────────┼─────────┼───────────────────┼───────────╢
║ query-string                            │   10000 │  273968.62 op/sec │  ± 1.48 % ║
║ qs                                      │    9999 │  324118.68 op/sec │  ± 0.99 % ║
║ querystringify                          │    1000 │  410157.64 op/sec │  ± 0.68 % ║
║ @aws-sdk/querystring-parser             │    1000 │  431465.20 op/sec │  ± 0.83 % ║
║ URLSearchParams-with-Object.fromEntries │    5000 │  833939.19 op/sec │  ± 0.97 % ║
║ URLSearchParams-with-construct          │   10000 │  980017.92 op/sec │  ± 2.42 % ║
║ node:querystring                        │   10000 │ 1068165.86 op/sec │  ± 3.41 % ║
║ querystringparser                       │    3000 │ 1384001.31 op/sec │  ± 0.95 % ║
╟─────────────────────────────────────────┼─────────┼───────────────────┼───────────╢
║ Fastest test                            │ Samples │            Result │ Tolerance ║
╟─────────────────────────────────────────┼─────────┼───────────────────┼───────────╢
║ fast-querystring                        │   10000 │ 1584458.62 op/sec │  ± 2.64 % ║
╚═════════════════════════════════════════╧═════════╧═══════════════════╧═══════════╝

• Stringify a query-string

> node benchmark/stringify.mjs

╔══════════════════════════════╤═════════╤═══════════════════╤═══════════╗
║ Slower tests                 │ Samples │            Result │ Tolerance ║
╟──────────────────────────────┼─────────┼───────────────────┼───────────╢
║ query-string                 │   10000 │  314662.25 op/sec │  ± 1.08 % ║
║ qs                           │    9500 │  353621.74 op/sec │  ± 0.98 % ║
║ http-querystring-stringify   │   10000 │  372189.04 op/sec │  ± 1.48 % ║
║ @aws-sdk/querystring-builder │   10000 │  411658.63 op/sec │  ± 1.67 % ║
║ URLSearchParams              │   10000 │  454438.85 op/sec │  ± 1.32 % ║
║ querystringparser            │   10000 │  455615.18 op/sec │  ± 4.22 % ║
║ querystringify               │   10000 │  879020.96 op/sec │  ± 2.12 % ║
║ querystringify-ts            │   10000 │  879134.48 op/sec │  ± 2.19 % ║
║ node:querystring             │   10000 │ 1244505.97 op/sec │  ± 2.12 % ║
╟──────────────────────────────┼─────────┼───────────────────┼───────────╢
║ Fastest test                 │ Samples │            Result │ Tolerance ║
╟──────────────────────────────┼─────────┼───────────────────┼───────────╢
║ fast-querystring             │   10000 │ 1953717.60 op/sec │  ± 3.16 % ║
╚══════════════════════════════╧═════════╧═══════════════════╧═══════════╝

• Importing package.

> node benchmark/import.mjs

╔═════════════════════════════╤═════════╤═════════════════╤═══════════╗
║ Slower tests                │ Samples │          Result │ Tolerance ║
╟─────────────────────────────┼─────────┼─────────────────┼───────────╢
║ @aws-sdk/querystring-parser │    1000 │ 12360.51 op/sec │  ± 0.57 % ║
║ qs                          │    1000 │ 14507.74 op/sec │  ± 0.36 % ║
║ querystringify              │    1000 │ 14750.53 op/sec │  ± 0.39 % ║
║ query-string                │    1000 │ 16335.05 op/sec │  ± 0.87 % ║
║ querystringparser           │    1000 │ 17018.50 op/sec │  ± 0.42 % ║
╟─────────────────────────────┼─────────┼─────────────────┼───────────╢
║ Fastest test                │ Samples │          Result │ Tolerance ║
╟─────────────────────────────┼─────────┼─────────────────┼───────────╢
║ fast-querystring            │    2500 │ 74605.83 op/sec │  ± 0.91 % ║
╚═════════════════════════════╧═════════╧═════════════════╧═══════════╝

fast-querystring's Issues

Run benchmark on every pull request

We should definitely add a command to run benchmarks on every pull request and add a comment for the result

some optimizations?

@anonrig

fast-querystring/lib/parse.js

Lines 44 to 45 in 212c51c

	key = key.replace(/\+/g, " ");
	value = value.replace(/\+/g, " ");

.replaceAll('+', ' ') is probably faster than the regex variant.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll

fast-querystring/lib/parse.js

Line 27 in 212c51c

if (c === 38 || isNaN(c)) {

Number.isNaN() is more robust

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN

Potentially upstream the code to node

Hey @anonrig, huge fan! ;)

Just wanted to ask if there is a reason why this package is not being merged to node itself if it is faster and API compatible?

Thanks in advance!

some optimizations?

@anonrig

fast-querystring/lib/parse.js

Lines 44 to 45 in 212c51c

	key = key.replace(/\+/g, " ");
	value = value.replace(/\+/g, " ");

.replaceAll('+', ' ') is probably faster than the regex variant.

fast-querystring/lib/parse.js

Line 27 in 212c51c

if (c === 38 || isNaN(c)) {

Number.isNaN() is more robust

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN

Use fast-decode-uri-component instead of decodeURIComponent

We used to use fast-decode-uri-component instead of decodeURIComponent for decoding path params in the find-my-way before we found a more efficient way to do this. It's just a suggestion, I don't remember the perf difference, but you can check it if you find it interesting.

Investigate size increase

We should investigate if the size increase is worth the performance gain, that is included in the latest release.

Received a feedback on Twitter

According to Bundlephobia

• 1.0.0 is 3.6 kb (minified)
• 1.1.0 is 748 kb (minified)

Add supporting metadata to benchmarks

Would be beneficial for the benchmark table to have supporting information such as:

• Specs of the machine running the benchmarks
• Node version
• Run date and time

Similar to https://github.com/fastify/benchmarks#benchmarks

This would allow viewers to know how current/accurate the benchmarks are.

Adding Benchmark and Test For Browser and Maybe Edge Runtime

Hi,

I understand that the goal of this library is to replace legacy node:querystring and is intended to be used in the Node environment.

But the benchmark also runs against other libraries that run on the browser.

So, based on the discussion I have with my team (notes that I'm a Product Manager, not a web developer), when the team is using a platform like NextJS, for example, they wanted to know whether the library will work in either Node and Edge environment (SSR), or on the browser (CSR).

So I have a few suggestions related to this:

1. You can make it clear in the documentation that it is not recommended or untested for this library to be used in the browser or non-Node environment

2. You can also add a test to use this on Edge and Browser environment

3. And related to performance to not only show benchmark related to how fast the library is doing specific operations (i.e., stringifying) but also how it will impact other metrics such as CPU and memory load (which will affect infra cost) and also Time to First Byte and Page Load (when running on the browser). This will show a complete picture of the tradeoff and when to use or not use this library.

I like what you guys are doing, and I hope this feedback will improve the library.

Sincerely,