Benchmark: URLSearchParams impact

Script Preparation code:

function getTokenA(){
  return (
    sessionStorage.getItem("token") || // session storage is used for single session logins (agency users)
    localStorage.getItem("token") // local storage is used for persistent logins (normal users)
  );
};

function getTokenB() {
  return (
    new URLSearchParams(window.location.search).get("token") || // query param is used to quickly override the token
    sessionStorage.getItem("token") || // session storage is used for single session logins (agency users)
    localStorage.getItem("token") // local storage is used for persistent logins (normal users)
  );
};

localStorage.setItem("token", "something")

Tests:

without URLSearchParams
getTokenA()
with URLSearchParams
getTokenB()

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
without URLSearchParams
with URLSearchParams

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

Browser/OS: Chrome 128 on Windows

View result in a separate tab

Test name	Executions per second
without URLSearchParams	3203525.2 Ops/sec
with URLSearchParams	1330808.1 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks!

The provided JSON represents a benchmarking test created on MeasureThat.net, which aims to compare the performance of two different approaches for retrieving a token from storage. The token is used for authentication purposes.

**Tested options:**

1. **Token retrieval without `URLSearchParams`**: This approach uses session storage and local storage to retrieve the token. It checks both storage locations sequentially.
2. **Token retrieval with `URLSearchParams`**: This approach also uses session storage and local storage, but it first parses the URL query string using `URLSearchParams` to retrieve the token.

**Pros and cons of each approach:**

1. **Without `URLSearchParams`:**
	* Pros:
		+ Simple and straightforward implementation.
		+ Less overhead due to parsing the URL query string.
	* Cons:
		+ May be slower if the token is not cached in session storage or local storage.
2. **With `URLSearchParams`:**
	* Pros:
		+ Can potentially be faster since it only checks the query string once.
		+ Reduces the number of cache hits for retrieving the token.
	* Cons:
		+ Requires parsing the URL query string, which can introduce additional overhead.

**Library used:**

In both test cases, `URLSearchParams` is used to parse the URL query string. This library provides a convenient way to access query parameters in JavaScript.

**Special JS feature or syntax:**

None of the provided code snippet uses any special JavaScript features or syntax. However, it's worth noting that using `URLSearchParams` is a modern JavaScript feature introduced in ECMAScript 2015 (ES6).

**Other alternatives:**

If you wanted to compare these approaches without using `URLSearchParams`, you could use other methods to retrieve the token from the query string, such as:

1. Using a regular expression to extract the token from the URL.
2. Parsing the URL manually and extracting the query parameters.

However, these approaches would likely be less efficient and more error-prone than using `URLSearchParams`.

In summary, the benchmark tests on MeasureThat.net aim to compare the performance of two token retrieval approaches: one without using `URLSearchParams` and another with it. The results will help identify which approach is faster and more efficient in retrieving the token for authentication purposes.

Related benchmarks:

URLSearchParams impact (version: 0)

Comparing performance of: without URLSearchParams vs with URLSearchParams

Created: one year ago by: Guest

Jump to the latest result

without URLSearchParams

with URLSearchParams

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):