Benchmark: Template literals + regex vs safe accessor

Script Preparation code:

var toBoolean1 = value => !! ( `${ value }`.match( /true/i ));
 var toBoolean2 = value => !! (
     value === true
     || value?.toLowerCase?.() === 'true'
 );

Tests:

toBoolean1
toBoolean1 ( 'tRue' );
toBoolean2
toBoolean2 ( 'tRue' );
toBoolean1 2
toBoolean1 ( true );
toBoolean2 2
toBoolean2 ( true );
toBoolean1 3
toBoolean1 ( 'false' );
toBoolean2 3
toBoolean2 ( 'false' );

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
toBoolean1
toBoolean2
toBoolean1 2
toBoolean2 2
toBoolean1 3
toBoolean2 3

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks on MeasureThat.net.

**Benchmark Definition JSON**

The provided benchmark definition JSON describes two functions, `toBoolean1` and `toBoolean2`, which aim to convert a given value to a boolean using different approaches. The main difference lies in how they handle the string 'true'.

**Options Compared**

There are two options being compared:

1. **Template literals + regex (`toBoolean1`)**: This approach uses template literals to create a string containing the input value, followed by an expression that matches the string `/true/i`. If a match is found, the expression returns `true`, otherwise it returns `false`.
2. **Safe accessor (`toBoolean2`)**: This approach uses safe accessor syntax (optional chaining) to check if the input value is equal to `true` or if its lowercase version is equal to `'true'`.

**Pros and Cons**

*   **Template literals + regex**: The main advantage of this approach is that it is concise and expressive. However, using template literals can lead to performance overhead due to string creation and matching. Additionally, the use of an external regex function can add complexity.
*   **Safe accessor**: This approach has the benefit of being more explicit and readable. It also avoids potential issues with string matching, making it more predictable. However, its syntax might be less familiar to some developers.

**Library Used**

There is no explicit library mentioned in the benchmark definition JSON, but we can infer that the `match()` method is used within the template literals, which implies the use of JavaScript's built-in string matching functionality or an external regex library.

**Special JS Feature/Syntax**

The safe accessor syntax (`?.`) and optional chaining (`.toLowerCase?.()`) are modern JavaScript features introduced in ECMAScript 2018. These features allow developers to access nested properties and handle null/undefined values in a more concise way.

Latest run results:

Run details: (Test run date: 2 years ago)

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

Browser/OS: Chrome 99 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
toBoolean1	8198004.0 Ops/sec
toBoolean2	14635185.0 Ops/sec
toBoolean1 2	8155793.0 Ops/sec
toBoolean2 2	14577147.0 Ops/sec
toBoolean1 3	9919168.0 Ops/sec
toBoolean2 3	14661698.0 Ops/sec

Related benchmarks:

Template literals + regex vs safe accessor (version: 0)

Comparing performance of: toBoolean1 vs toBoolean2 vs toBoolean1 2 vs toBoolean2 2 vs toBoolean1 3 vs toBoolean2 3

Created: 4 years ago by: Guest

Jump to the latest result

toBoolean1

toBoolean2

toBoolean1 2

toBoolean2 2

toBoolean1 3

toBoolean2 3

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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