Benchmark: parseInt vs charCodeAt

Script Preparation code:

var strings = [
    "6",
    "4",
    "3",
    "4",
    "1",
    "1",
    "5",
    "4",
    "1",
    "3",
    "2",
    "2",
    "5",
    "7",
    "1",
    "2",
    "1",
    "0",
    "5",
    "7",
    "4",
    "5",
    "0",
    "5",
    "1",
    "0",
    "4",
    "1",
    "7",
    "7",
    "0",
    "4",
    "0",
    "6",
    "3",
    "7",
    "7",
    "7",
    "5",
    "0",
    "0",
    "5",
    "0",
    "3",
    "3",
    "0",
    "5",
    "0",
    "2",
    "6",
    "2",
    "3",
    "3",
    "6",
    "2",
    "3",
    "0",
    "5",
    "5",
    "5",
    "6",
    "2",
    "3",
    "4",
    "4",
    "0",
    "7",
    "2",
    "3",
    "2",
    "6",
    "1",
    "4",
    "1",
    "1",
    "6",
    "5",
    "7",
    "4",
    "2",
    "5",
    "4",
    "6",
    "3",
    "4",
    "5",
    "4",
    "6",
    "1",
    "0",
    "3",
    "4",
    "7",
    "1",
    "0",
    "5",
    "4",
    "5",
    "3",
    "6"
];

Tests:

parseInt
for (let s of strings) { let a = parseInt(s[0]); }
charCodeAt
for (let s of strings) { let a = s.charCodeAt(0) - 48; }

Historical Performance Data aggregated from 6 community runs

Desktop Results:

Chrome 6 runs

charCodeAt

5.3M/s

parseInt

126K/s

Fastest: charCodeAt (41.7x faster)

View exact numbers

✓ charCodeAt: 5,265,359 ops/sec
• parseInt: 126,323 ops/sec

Results show median performance across all community submissions. Run this benchmark yourself to verify on your device.

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
parseInt
charCodeAt

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 135 on Mac OS X 10.15.7

View result in a separate tab

charCodeAt

1.5M/s

parseInt

1.1M/s

View exact numbers

Test name	Executions per second
✓ charCodeAt	1,496,112 Ops/sec
parseInt	1,133,227 Ops/sec

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

LLMs can make mistakes. Check important info.

I'll provide an explanation of the benchmark, its options, pros and cons, and other considerations.

**Benchmark Overview**

The test compares the performance of two approaches to convert a character to an integer: `parseInt` and `charCodeAt`. The input data consists of an array of strings, where each string represents a single-digit number from 0 to 9.

**Options Compared**

There are only two options being compared:

1. **`parseInt(s[0])`**: This approach converts the first character of each string to an integer using the `parseInt` function.
2. **`s.charCodeAt(0) - 48`**: This approach directly accesses the Unicode code point of the first character of each string and subtracts 48 (since '0' has a Unicode code point of 48) to convert it to an integer.

**Pros and Cons**

1. **`parseInt(s[0])`**:
	* Pros: More concise and readable, as it uses a standard function.
	* Cons: May be slower due to the overhead of function calls, especially in older browsers or with slow JavaScript engines.
2. **`s.charCodeAt(0) - 48`**:
	* Pros: Can be faster since it avoids the overhead of function calls and directly accesses the Unicode code point.
	* Cons: Less readable and more verbose, as it requires manual subtraction.

**Library Used**

In this benchmark, no external libraries are used. The `parseInt` function is a built-in JavaScript function, while the `charCodeAt` method is also a built-in method of strings in JavaScript.

**Special JS Feature or Syntax**

There is no special JS feature or syntax being tested here; both options use standard JavaScript features (functions and string methods).

**Other Considerations**

When optimizing performance-critical code, it's essential to consider the trade-offs between readability, maintainability, and execution speed. In this case:

* For small datasets and fast JavaScript engines, `parseInt` might be sufficient and readable.
* For large datasets or slower JavaScript engines, `charCodeAt` might provide a slight performance boost due to its simplicity.

**Alternatives**

If you need to convert characters to integers in other contexts, consider the following alternatives:

1. **Use a dedicated library**: Libraries like `punycode` (for URL encoding) or `decimal.js` (for decimal arithmetic) offer optimized implementations of character-to-integer conversions.
2. **Implement a custom solution**: If performance is critical and you have control over the code, consider implementing a custom solution using bitwise operations or lookup tables to achieve optimal performance.

Keep in mind that the choice of approach ultimately depends on your specific use case, target audience, and performance requirements.

parseInt vs charCodeAt (version: 0)

Comparing performance of: `parseInt vs charCodeAt`

Created: 3 years ago by: Guest

Go to the latest result

parseInt

charCodeAt

Historical Performance Data aggregated from 6 community runs

Desktop Results:

Chrome 6 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

parseInt vs charCodeAt (version: 0)

Comparing performance of: parseInt vs charCodeAt

Created: 3 years ago by: Guest

Go to the latest result

parseInt

charCodeAt

Historical Performance Data aggregated from 6 community runs

Desktop Results:

Chrome 6 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

Related benchmarks

Comparing performance of: `parseInt vs charCodeAt`