Benchmark: URLSearchParams vs Custom

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()
}

Tests:

Custom Encode
encode(queryobj)
Native Encode
encodeNative(queryobj)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Custom Encode
Native Encode

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):

LLMs can make mistakes. Check important info.

Let's break down the benchmark and explain what's being tested.

**Overview**

The benchmark compares two approaches to encoding URL query parameters: a custom implementation (`encode`) and the native `URLSearchParams` API.

**Custom Implementation**

The custom implementation is defined in the "Script Preparation Code" section of the benchmark definition. It takes an object as input, iterates over its properties, and appends each key-value pair to a string, separated by ampersands (`&`). The resulting string is then returned.

**Native URLSearchParams API**

The native `URLSearchParams` API is used for encoding query parameters in URLs. This API is part of the browser's URL manipulation functionality and allows you to create an object that can be converted to a URL string.

**Comparison**

The benchmark compares the performance of these two approaches on the same input data (`queryobj`). The test cases are defined in the "Individual test cases" section, which specify the function calls to execute for each approach:

* `Custom Encode`: Calls the custom implementation with the `encode` function and the `queryobj` object as arguments.
* `Native Encode`: Calls the native `URLSearchParams` API with the `encodeNative` function and the `queryobj` object as arguments.

**Pros and Cons**

Here are some pros and cons of each approach:

* **Custom Implementation**:
	+ Pros: Can be more flexible, allowing for custom encoding rules or additional data to be included.
	+ Cons: May be slower, less efficient, and more prone to errors due to its manual implementation.
* **Native URLSearchParams API**:
	+ Pros: Faster, more efficient, and more reliable, as it's optimized for URL manipulation.
	+ Cons: Less flexible, as it relies on the browser's built-in functionality.

**Library**

The `URLSearchParams` API is a part of the Web API, which provides standardized interfaces for working with URLs in web applications. This library allows you to easily manipulate and encode query parameters in URLs.

**Special JS Feature or Syntax**

There isn't any special JavaScript feature or syntax mentioned in this benchmark. The focus is on comparing two different approaches to encoding URL query parameters.

**Alternatives**

Other alternatives for encoding URL query parameters include:

* Using a library like jQuery's `jQuery.extend` function
* Implementing your own custom encoding logic using regular expressions or string manipulation functions

However, the native `URLSearchParams` API is generally considered the most efficient and reliable way to encode query parameters in URLs.

Latest run results:

Run details: (Test run date: 20 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
Custom Encode	6576705.5 Ops/sec
Native Encode	1565700.0 Ops/sec

Related benchmarks:

URLSearchParams vs Custom (version: 0)

Comparing performance of: Custom Encode vs Native Encode

Created: 2 years ago by: Guest

Jump to the latest result

Custom Encode

Native Encode

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):