Benchmark: Custom Build Query 3

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;
}

function buildQueryString2(params) {
  const filteredParams = Object.fromEntries(
    Object.entries(params).filter(([_, value]) => value != null)
  );
  const query = new URLSearchParams(filteredParams).toString();
  return query ? `?${query}` : '';
}

Tests:

URLSearchParams
encodeNative(queryobj)
Custom (safe)
buildQueryString(queryobj)
Custom 2 (unsafe)
encode(queryobj)
Custom (fast)
fastBuildQueryString(queryobj)
Custom (both)
buildQueryString2(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)
Custom (both)

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated 15 hours ago):

LLMs can make mistakes. Check important info.

The provided benchmark consists of several test cases aimed at measuring the performance of different functions for building query strings from an object of parameters in JavaScript. The primary focus is to compare custom implementations of query string builders against the native `URLSearchParams` approach.

### Test Cases and Their Descriptions:

1. **Test Name: `URLSearchParams`**
   - **Benchmark Definition:** `encodeNative(queryobj)`
   - This uses the native `URLSearchParams` API which offers a straightforward and efficient way to encode an object into a query string. 
   - **Pros:** Supports automatic handling of special characters and ensures correct encoding. It is part of the native JavaScript environment and often optimized by the browser.
   - **Cons:** May not handle certain cases (like custom validation or encoding logic) which developers might need.

2. **Test Name: `Custom (safe)`**
   - **Benchmark Definition:** `buildQueryString(queryobj)`
   - This implementation uses `Object.entries()` to filter and build the query string.
   - **Pros:** It converts the object into a query string while allowing control over how parameters are encoded (e.g., escaping special characters using `encodeURIComponent`).
   - **Cons:** Potentially less efficient due to the multiple iterations over the object's properties.

3. **Test Name: `Custom 2 (unsafe)`**
   - **Benchmark Definition:** `encode(queryobj)`
   - This function builds a query string without filtering out the parameter values beyond checking for `null`.
   - **Pros:** Simple implementation and can be quick for straightforward data.
   - **Cons:** It is labeled as "unsafe" because it does not encode values properly, which could lead to injection vulnerabilities or incorrect results with special characters.

4. **Test Name: `Custom (fast)`**
   - **Benchmark Definition:** `fastBuildQueryString(queryobj)`
   - This implementation optimizes the query string building by avoiding additional iterations and instead handles parameter checks in a single pass.
   - **Pros:** More efficient (faster) compared to the other methods with fewer iterations.
   - **Cons:** It may be less readable and could miss advanced encoding needs.

5. **Test Name: `Custom (both)`**
   - **Benchmark Definition:** `buildQueryString2(queryobj)`
   - This approach filters null/undefined values and uses `URLSearchParams` to produce the final query string.
   - **Pros:** Combines benefits of filtering out invalid entries and utilizes native functionality for encoding.
   - **Cons:** Relies on both filtering and `URLSearchParams`, which adds overhead compared to simpler methods.

### Results Discussion:

The benchmark results showcase the performance across the different test cases measured in executions per second. Notably:

- **Best Performer:** `Custom 2 (unsafe) with 5,828,196 executions/second`, highlighting that the simplest implementation can sometimes outperform more robust options.
- **Next Best:** `Custom (fast) with 3,258,112 executions/second`, indicating a good balance of speed while maintaining some level of safety.
- **Native Approach:** `URLSearchParams` index at 1,143,009 executions/second shows a respectable but slower performance due to its overhead.
  
### Other Considerations:

- **Use Cases:** The choice between these approaches depends on the specific requirements of safety, performance, and complexity. For high-performance scenarios, `Custom 2 (unsafe)` may be tempting, but it should be used with care due to potential security implications.
- **Alternatives:** Developers might consider third-party libraries like `qs`, `query-string`, or `axios` for more robust or feature-rich query string manipulation capabilities. These libraries often offer better handling of edge cases and complexities and are suitable when dealing with more significant data traversal or specific encoding needs.
- **Browser Support:** The choice of using native APIs versus custom implementations may also depend on the target environment and the importance of performance across different browsers.

In summary, evaluating these query string builders requires balancing performance against the needs for safety and correctness, with consideration for the specific context in which you are working.

Latest run results:

Run details: (Test run date: 16 hours 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	1143009.4 Ops/sec
Custom (safe)	1530682.0 Ops/sec
Custom 2 (unsafe)	5828196.0 Ops/sec
Custom (fast)	3258112.2 Ops/sec
Custom (both)	1077677.2 Ops/sec

Related benchmarks:

Custom Build Query 3 (version: 1)

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

Created: 16 hours ago by: Guest

Jump to the latest result

URLSearchParams

Custom (safe)

Custom 2 (unsafe)

Custom (fast)

Custom (both)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated 15 hours ago):