Benchmark: new RegExp vs literal

HTML Preparation code:

<!--your preparation HTML code goes here-->

Script Preparation code:

/*your preparation JavaScript code goes here
To execute async code during the script preparation, wrap it as function globalMeasureThatScriptPrepareFunction, example:*/
async function globalMeasureThatScriptPrepareFunction() {
    // This function is optional, feel free to remove it.
    // await someThing();
}

Tests:

match
const TAG_REGEX = /(\w+)/g; const str = 'aqui é uma <strong class="elm">questão</strong> de teste <img class="elm" onerror="opa"></img><br class="elm"/><iframe src="http://" class="iframeclass"/><iframe src="http://" class="iframeclass"/><iframe src="http://" class="iframeclass"/>'; str.match(TAG_REGEX)
new RegExp
const str = 'aqui é uma <strong class="elm">questão</strong> de teste <img class="elm" onerror="opa"></img><br class="elm"/><iframe src="http://" class="iframeclass"/><iframe src="http://" class="iframeclass"/><iframe src="http://" class="iframeclass"/>'; str.match(new RegExp("(\\w+)", "g"))

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
match
new RegExp

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) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

Browser/OS: Chrome 136 on Linux

View result in a separate tab

match

1.2M/s

new RegExp

1.1M/s

View exact numbers

Test name	Executions per second
✓ match	1,214,196 Ops/sec
new RegExp	1,062,401 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated one year ago):

LLMs can make mistakes. Check important info.

The benchmark titled "new RegExp vs literal" examines the performance of two different ways of defining a regular expression in JavaScript: using a regular expression literal and using the `RegExp` constructor. The main focus of this benchmark is to compare:

1. **Regular Expression Literal**: 
   - Defined using `const TAG_REGEX = /(\\w+)/g;`
   - The regular expression is directly written within slashes.

2. **RegExp Constructor**: 
   - Defined with `const str.match(new RegExp("(\\\\w+)", "g"));`
   - This approach uses the `RegExp` constructor to create a regular expression from a string.

### Test Cases

1. **Test Case: `match`**
   - In this case, the regular expression literal is applied to match patterns in an HTML-like string using `str.match(TAG_REGEX)`.
   - **Performance Result**: `1214196.0` executions per second.

2. **Test Case: `new RegExp`**
   - Here, the `new RegExp()` constructor is used to achieve the same matching process on the same string with `str.match(new RegExp("(\\\\w+)", "g"))`.
   - **Performance Result**: `1062400.875` executions per second.

### Pros and Cons

**Regular Expression Literal (`/expression/`)**:
- **Pros**:
  - More concise and easier to read.
  - Generally faster performance because the engine can compile this at the time of writing the code.
  
- **Cons**:
  - Less flexible if dynamic patterns are required (e.g., if the pattern needs to change based on variables).

**RegExp Constructor (`new RegExp()`)**:
- **Pros**:
  - Provides flexibility since you can dynamically create regex patterns using variable data.
  - Useful for situations where the pattern might not be known until runtime.

- **Cons**:
  - The performance is generally slower due to the overhead of string parsing and compilation at runtime.
  - Can be less readable, especially if the expression gets complex.

### Other Considerations
The results show that the regex literal is faster than using the `RegExp` constructor in this particular benchmark. This is often observed in performance tests and is indicative of how JavaScript engines optimize literal regex patterns.

### Alternatives
When it comes to working with regular expressions in JavaScript, other alternatives include:

- **Using Flags**: Both approaches can utilize flags such as `i` for case-insensitive matching, `m` for multi-line matching, etc.
- **Precompiled Patterns**: If you are using the same regex multiple times, it is often beneficial to cache regex literals, as they are compiled once and can be reused.
- **String Methods**: In some cases, alternative string methods (`String.prototype.includes`, `String.prototype.startsWith`, `String.prototype.endsWith`) can be used if the pattern is simple enough, thereby avoiding regex altogether.

This benchmark clearly highlights a critical choice faced by developers: whether to prioritize performance with regex literals or flexibility with the `RegExp` constructor, depending on the use case at hand.

new RegExp vs literal (version: 1)

Comparing performance of: `match vs new RegExp`

Created: one year ago by: Guest

Go to the latest result

match

new RegExp

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated one year ago):

new RegExp vs literal (version: 1)

Comparing performance of: match vs new RegExp

Created: one year ago by: Guest

Go to the latest result

match

new RegExp

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated one year ago):

Related benchmarks

Comparing performance of: `match vs new RegExp`