Benchmark: RegExp constructor vs inline literal

Script Preparation code:

var reConstructor = new RegExp('^[0-9a-fA-F]{24}$')

Tests:

new RegExp()
reConstructor.test('132abc67219f019afe12901a')
Inline literal
/^[0-9a-fA-F]{24}$/.test('132abc67219f019afe12901a')

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
new RegExp()
Inline literal

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks!

**Benchmark Overview**

The provided benchmark measures the performance difference between using the `RegExp` constructor to create a new regular expression object versus using an inline literal (a string enclosed in forward slashes `/`). The test consists of two individual test cases: one that uses the `new RegExp()` method and another that uses an inline literal.

**What is tested?**

In this benchmark, we're testing the performance difference between creating a new `RegExp` object using the constructor versus using an inline literal. Specifically:

* `new RegExp('^[0-9a-fA-F]{24}$')`: Creates a new regular expression object with the specified pattern.
* `/^[0-9a-fA-F]{24}$/`: Uses an inline literal to define the same regular expression.

**Options compared**

We're comparing two approaches:

1. **`new RegExp()`**: Creates a new `RegExp` object, which involves parsing and compiling the regular expression pattern.
2. **Inline Literal (`/...$/`)**: Uses an inline literal to define the regular expression pattern, which is essentially a string that represents the regex.

**Pros and Cons**

Here's a brief summary of the pros and cons of each approach:

* `new RegExp()`:
	+ Pros: Can be more readable and easier to maintain for complex regex patterns.
	+ Cons: May incur additional overhead due to parsing and compilation, which can impact performance.
* Inline Literal (`/...$/`):
	+ Pros: Typically faster and more efficient than using the `RegExp` constructor.
	+ Cons: Can be less readable and harder to maintain for complex regex patterns.

**Library usage**

In this benchmark, no specific JavaScript library is used. The test cases only involve built-in JavaScript functionality.

**Special JS feature or syntax**

There are a few aspects of JavaScript that might be worth noting:

* **Template literals**: Although not explicitly mentioned in the benchmark, template literals (introduced in ECMAScript 2015) provide a concise way to define inline regex patterns. However, this feature is not used in the provided benchmark.
* **String methods**: The test cases utilize string methods like `test()` and `includes()`, which are part of the JavaScript standard library.

**Other alternatives**

If you wanted to explore alternative approaches, consider the following:

* Using a dedicated regex engine or library, such as `regex-test` (a Node.js module) or `regex-quickcheck` (a command-line tool).
* Employing other optimization techniques, like caching or memoization, to improve performance.

Keep in mind that these alternatives might not be directly applicable to the specific use case presented in this benchmark.

Latest run results:

Run details: (Test run date: 10 months ago)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Browser/OS: Chrome 120 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
new RegExp()	13580690.0 Ops/sec
Inline literal	21592830.0 Ops/sec

Related benchmarks:

RegExp constructor vs inline literal (version: 0)

Testing performance when using a new RegExp object vs a literal regex

Comparing performance of: new RegExp() vs Inline literal

Created: 10 months ago by: Guest

Jump to the latest result

new RegExp()

Inline literal

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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