Benchmark: regex capture groups test

Tests:

A
'https://spray.widen.net/content/oqnfu4pcak/web/patterns-other-full-cone-group-660x370.jpeg'.match( /(?<width>[0-9]{2,})x[0-9]{2,}.*\.jpe?g/i)
B
'https://spray.widen.net/content/oqnfu4pcak/web/patterns-other-full-cone-group-660x370.jpeg'.match( /(?<width>[0-9]{2,})x[0-9]{2,}.*\.jp(e)?g/i)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
A
B

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Browser/OS: Firefox 128 on Linux

View result in a separate tab

Test name	Executions per second
A	3436978.0 Ops/sec
B	3267425.5 Ops/sec

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

LLMs can make mistakes. Check important info.

**What is tested on the provided JSON?**

The provided JSON represents a JavaScript microbenchmark test case, specifically designed to measure the performance of regular expression capture groups. The benchmark is testing two different approaches:

1. Approach A: Using `.*` in the regular expression pattern to match any characters (including newline) before capturing the width and height values.
2. Approach B: Using `.jp(e)?g` in the regular expression pattern to match JPEG files, which will likely be more efficient than the first approach.

**Options compared**

The two approaches differ in their regular expression patterns:

* Approach A uses `.*`, which matches any character (including newline) before capturing the width and height values.
* Approach B uses `.jp(e)?g`, which is designed to match JPEG files (.jpg or .jpeg).

**Pros and Cons of each approach:**

1. **Approach A (`.match(\r\n    /(?<width>[0-9]{2,})x[0-9]{2,}.*\.jpe?g/i)`)**:
	* Pros:
		+ More flexible, as it can match any URL with width and height values.
	* Cons:
		+ May be slower due to the more general pattern matching `.*`.
2. **Approach B (`.match(\r\n    /(?<width>[0-9]{2,})x[0-9]{2,}.*\.jp(e)?g/i)`)**:
	* Pros:
		+ More efficient, as it specifically targets JPEG files.
	* Cons:
		+ Less flexible, as it only matches a specific format.

**Library usage**

None of the provided benchmarks use any external libraries.

**Special JS feature or syntax**

The benchmark uses:

* **Template literals**: The regular expression patterns are defined using template literals (`\r\n    /` ... `i)` to create a multi-line string.
* **Regular expressions**: The benchmark uses regular expressions to match URLs and extract values.

**Other considerations**

* **Image processing**: The benchmark is designed to measure the performance of regular expression capture groups on image URLs, which may involve additional overhead due to image processing.
* **Browser differences**: The benchmark results are reported for different browsers (Chrome), devices (Desktop, Mac OS X 10.15.7), and operating systems (Mac OS X 10.15.7).

**Alternatives**

Other alternatives to this benchmark could include:

* Testing regular expression performance on strings or arrays of data.
* Comparing the performance of different JavaScript engines (e.g., V8, SpiderMonkey).
* Measuring the performance of regular expression libraries or frameworks like RegEx.js or regex-lint.

Related benchmarks:

regex capture groups test (version: 0)

Comparing performance of: A vs B

Created: 3 years ago by: Guest

Jump to the latest result

A

B

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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