Benchmark: Custom Build Query 2

Script Preparation code:

var querystring = 'foo=bar&baz=qux&quxx=corge&grault=garply&waldo=fred&plugh=xyzzy'

var queryobj = {
  foo: 'bar',
  baz: 'qux',
  quux: 'corge',
  grault: 'garply',
  waldo: 'fred',
  plugh: 'xyzzy'
}

function encode(data) {
  let result = '?'

  for (const key in data) {
    if (data[key] != null) {
      result += key + '=' + data[key] + '&'
    }
  }

  return result.slice(0, -1)
}

function encodeNative(data) {
  return new URLSearchParams(data).toString()
}

function buildQueryString(params) {
  const query = Object.entries(params)
    .filter(([_, value]) => value !== undefined && value !== null)
    .map(([key, value]) => `${key}=${encodeURIComponent(String(value))}`)
    .join('&');

  return query ? `?${query}` : '';
}

function fastBuildQueryString(params) {
  let result = '?';
  let first = true;
  
  for (const key of Object.keys(params)) {
    const value = params[key];
    if (value != null) {
      if (!first) result += '&';
      result += key + '=' + encodeURIComponent(String(value));
      first = false;
    }
  }
  
  return first ? '' : result;
}

Tests:

URLSearchParams
encodeNative(queryobj)
Custom (safe)
buildQueryString(queryobj)
Custom 2 (unsafe)
encode(queryobj)
Custom (fast)
fastBuildQueryString(queryobj)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
URLSearchParams
Custom (safe)
Custom 2 (unsafe)
Custom (fast)

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one month ago)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1 Safari/605.1.15

Browser/OS: Safari 18 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
URLSearchParams	1544708.1 Ops/sec
Custom (safe)	1561038.0 Ops/sec
Custom 2 (unsafe)	5033470.0 Ops/sec
Custom (fast)	3234752.2 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated one month ago):

LLMs can make mistakes. Check important info.

The benchmark defined in the provided JSON measures the performance of different methods for constructing query strings from an object of parameters in JavaScript. The focus is on comparing various custom implementations against the native `URLSearchParams` API. Here’s a deeper look into each method, the pros and cons of the approaches, and additional considerations.

### Tested Methods

1. **encode(queryobj)** - *Custom 2 (unsafe)*
   - **Description:** This method constructs a query string by concatenating key-value pairs from the passed object, where the key and value are directly written into the resulting string.
   - **Pros:** Simplicity in implementation.
   - **Cons:** This method does not apply escaping for potentially unsafe characters in the key or value, leading to potential issues with malformed URLs or security vulnerabilities (e.g., XSS attacks).

2. **buildQueryString(params)** - *Custom (safe)*
   - **Description:** Utilizes `Object.entries` to iterate over parameters, uses `encodeURIComponent` to safely escape key-value pairs, and constructs the query string.
   - **Pros:** Safeguards against malformed data by ensuring that all characters are properly encoded, which is essential for building valid URLs.
   - **Cons:** This approach can be slower due to the additional overhead of using `encodeURIComponent` for each parameter.

3. **fastBuildQueryString(params)** - *Custom (fast)*
   - **Description:** Similar to `buildQueryString`, but optimizes performance by minimizing overhead; it avoids repeated checks to see if it should append an '&' by using a `first` flag.
   - **Pros:** Offers a balanced approach to speed and safety, by ensuring that parameters are still encoded safely while reducing the execution time relative to naive implementations.
   - **Cons:** Still requires usage of `encodeURIComponent`, and the checks for `null` or `undefined` could introduce slight overhead compared to the simplest implementations.

4. **encodeNative(queryobj)** - *URLSearchParams*
   - **Description:** Uses the native JavaScript API `URLSearchParams` to create a query string, leveraging its optimized implementation.
   - **Pros:** Built-in API that is often optimized by the JavaScript engine, resulting in high performance and automatic safety in terms of escaping special characters.
   - **Cons:** May have less flexibility if additional customizations are needed beyond what this API provides.

### Benchmark Results
The benchmark results indicate the number of executions per second for each method in a Safari 18 environment on Mac OS.

- **Best Performer:** `encode` (Custom 2 - unsafe) shows the highest performance, but at the cost of safety.
- **Moderate Performance:** `fastBuildQueryString` balances safety and speed.
- **Lowest Performance:** `buildQueryString` and `encodeNative` are among the slower methods due to their comprehensive handling of character encoding. Notably, `buildQueryString` took slightly more time than `encodeNative` but is still safer.
  
### Considerations
When selecting a method for query string construction in JavaScript, the choice often hinges on the specific use case:
- **Performance-Critical Applications:** If performance is paramount and the input is trusted, `encode` might be attractive due to its speed, although it poses security risks.
- **General Use with Safety Needs:** `URLSearchParams` or `buildQueryString` should be used in applications that handle untrusted input or require strict formation of URLs.
- **Custom Solutions:** If you need something tailored to your specific requirements or performance targets, consider modifying `fastBuildQueryString` or building upon it.

### Alternatives
In addition to the methods presented:
- **Third-Party Libraries:** Libraries such as [qs](https://www.npmjs.com/package/qs) or [query-string](https://www.npmjs.com/package/query-string) provide extensive features and are battle-tested in production scenarios. They often support nested objects and arrays, which built-in methods may not handle well.
- **Manual Concatenation:** For extremely simple cases with known data, manual string concatenation might be sufficient, although it's generally error-prone.

Ultimately, the choice of method significantly depends on the complexity of the data being serialized as well as the performance and safety needs of the application.

Related benchmarks:

Custom Build Query 2 (version: 1)

Comparing performance of: URLSearchParams vs Custom (safe) vs Custom 2 (unsafe) vs Custom (fast)

Created: one month ago by: Guest

Jump to the latest result

URLSearchParams

Custom (safe)

Custom 2 (unsafe)

Custom (fast)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated one month ago):