Benchmark: .endsWith vs includes longer

Script Preparation code:

var string = '.php'
var stringToCheck = 'somethinglike.php'

var result = null

Tests:

.endsWith
result = stringToCheck.endsWith(string);
.includes
result = stringToCheck.includes(string);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
.endsWith
.includes

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36

Browser/OS: Chrome 144 on Linux

View result in a separate tab

Test name	Executions per second
.endsWith	6600557.0 Ops/sec
.includes	6853924.5 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and explain what's being tested.

**Benchmark Overview**

The benchmark compares the performance of two string manipulation methods in JavaScript: `endsWith` and `.includes`. The goal is to measure which method is faster for a specific use case.

**Options Compared**

Two options are compared:

1. **.endsWith**: This method checks if a string ends with another string.
2. **.includes**: This method checks if a string contains another string (i.e., is a substring of the original string).

**Pros and Cons of Each Approach**

*   `.endsWith`:
    *   Pros:
        *   More efficient for strings that are relatively short (due to early return).
        *   Fewer iterations over the source string.
    *   Cons:
        *   May be slower for very long strings (due to increased overhead from `length` checks).
*   `.includes`:
    *   Pros:
        *   More flexible, as it can be used with any substring search.
        *   Can handle longer strings more efficiently by avoiding unnecessary iterations.
    *   Cons:
        *   May be slower for short strings (due to increased overhead from looping over the source string).

**Library and Special JavaScript Features**

There are no libraries or special JavaScript features mentioned in this benchmark.

**Other Considerations**

When choosing between `.endsWith` and `.includes`, consider the following factors:

*   **String length**: For shorter strings, `.endsWith` might be faster. For longer strings, `.includes` might be more efficient.
*   **Substring search**: If you need to search for any substring within a string, use `.includes`.
*   **Early return**: Use `.endsWith` if you can take advantage of early returns (i.e., when the result is immediately apparent).

**Alternative Implementations**

While not explicitly mentioned in the benchmark, here are some alternative implementations:

*   **Regex-based approach**: You could use a regular expression to achieve both methods. For example:
    ```javascript
function endsWith(str, target) {
  return new RegExp(`^.*${target}$`).test(str);
}

function includes(str, target) {
  return str.includes(target);
}
```
    Keep in mind that this approach may introduce additional overhead due to the complexity of regular expressions.

*   **Native JavaScript implementation**: You could also attempt to implement these methods yourself using native JavaScript features like `slice()` and `indexOf()`. For example:
    ```javascript
function endsWith(str, target) {
  return str.slice(-target.length) === target;
}

function includes(str, target) {
  return str.indexOf(target) !== -1;
}
```
    However, this approach may not be as efficient or accurate as the built-in methods.

Keep in mind that while these alternatives exist, using the built-in `.endsWith` and `.includes` methods is often the best choice for performance and readability.

Related benchmarks:

.endsWith vs includes longer (version: 0)

Comparing performance of: .endsWith vs .includes

Created: 3 years ago by: Guest

Jump to the latest result

.endsWith

.includes

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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