Benchmark: Filter Cards - MeasureThat.net

Script Preparation code:

const cardMin = 12
const cardMax = 19
const cardSeparators = ['.', '_', '-', ' ']

window.filterCardsViaLoop = (str) => {
    if (str.length < cardMin) {
        return []
    }
    let nl = 0
    let ns = -1
    let i = 0
    const ni = []
    while (i < str.length) {
        if ((str.length - i) + nl < cardMin) {
            return ni
        }
        const c = str[i]
        const cc = c.charCodeAt(0)
        const isN = cc >= 48 && cc <= 57
        const isS = cardSeparators.includes(c)
        if (isN) {
            if (nl === 0) {
                ns = i
            }
            nl += 1
        } else if (!isS) {
            if (nl >= cardMin && nl <= cardMax) {
                ni.push([ns, i - 1])
            }
            nl = 0
        }
        i += 1
    }
    if (nl >= cardMin && nl <= cardMax) {
        ni.push([ns, i])
    }
    return ni
}

const regex = /[0-9 ]{12,19}/g
window.filterCardsViaRegex = (str) => {
    const ni = []
    while (true) {
        const matches = regex.exec(str)
        if (!matches) {
            break;
        }
        const lastIndex = regex.lastIndex
        ni.push([lastIndex, lastIndex + matches[0].length])
        i += 1
    }
    return ni
}

Tests:

Match via loop
filterCardsViaLoop('this string has a pan here => 411111111111 <=')
Match via regex
filterCardsViaRegex('this string has a pan here => 411111111111 <=')

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Match via loop
Match via regex

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Browser/OS: Firefox 98 on Windows

View result in a separate tab

Test name	Executions per second
Match via loop	709952.0 Ops/sec
Match via regex	2177291.8 Ops/sec

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

LLMs can make mistakes. Check important info.

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

**Benchmark Definition**

The benchmark compares two approaches to filter PAN (Payment Account Number) strings from a given input string:

1. **Filter Cards via Loop**: This approach uses a `for` loop to iterate through the input string, checking for PANs using a combination of regular expressions (`\d`) and character separators (`[.- ]`). The loop keeps track of the last valid index (`ns`) and returns an array of `[lastValidIndex, lastIndex]` pairs.
2. **Filter Cards via Regex**: This approach uses a regular expression (`/[^0-9][^0-9]?\d{12,19}/g`) to match PANs in the input string. The regex engine returns all matches, and the benchmark converts these matches into an array of `[lastIndex, lastIndex + matchLength]` pairs.

**Options Compared**

The two approaches are compared in terms of performance (number of executions per second).

**Pros and Cons**

* **Filter Cards via Loop**:
	+ Pros: Can be more intuitive for developers familiar with `for` loops.
	+ Cons: May be slower due to the overhead of a loop, especially for large input strings.
* **Filter Cards via Regex**:
	+ Pros: Can be faster, as regex engines are optimized for performance.
	+ Cons: Requires familiarity with regular expressions and may be more error-prone.

**Library Used**

The `regex` library is used to define the regular expression pattern. This library is a built-in JavaScript function that provides an easy-to-use interface for working with regular expressions.

**Special JS Feature/ Syntax**

The benchmark uses the `exec()` method, which returns the result of executing a regular expression on a string. The `lastIndex` property is used to store the index at which the regex engine started searching for matches again after finding a match.

**Other Considerations**

* The benchmark assumes that the input string contains PANs in the format described in the script.
* The `cardMin`, `cardMax`, and `cardSeparators` variables are hardcoded, but it's likely intended to make them configurable or customizable for specific use cases.
* The benchmark doesn't account for errors, such as mismatched characters or invalid input strings.

**Alternative Approaches**

Other approaches could be considered, such as:

* Using a dedicated library like `regex-escape` to escape special characters and improve regex performance.
* Implementing a custom PAN filtering algorithm that's optimized for specific use cases.
* Comparing the performance of other filtering techniques, such as using a trie data structure or a linear scan.

Related benchmarks:

Filter Cards (version: 1)

Compares filtering card PANs by regex vs a for loop

Comparing performance of: Match via loop vs Match via regex

Created: 2 years ago by: Registered User

Jump to the latest result

Match via loop

Match via regex

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):