Benchmark: Parse 32-bit hex | BigInt vs regex + parseInt

Script Preparation code:

var PAIRS = [];
for (let i = 0; i < 1000; ++i) {
  PAIRS.push([
    Math.round(Math.random() * 65535),
    Math.round(Math.random() * 65535),
  ]);
}

Tests:

BigInt
const serdeBigint = { read(value) { const value_u32 = BigInt(value); let minor = Number(value_u32) & ~0xFFFF_0000; const major = Number((value_u32 & ~BigInt(0x0000_FFFF)) >> BigInt(16)); while (minor >= 1) minor /= 10; return Math.round((major + minor) * 1e5) / 1e5; }, write(value) { let minor = Math.round((value % 1) * 1e5); const major = Math.round(value - (minor / 1e5)); while (minor && !(minor % 10)) minor /= 10; return `0x${ ((BigInt(major) << BigInt(16)) + BigInt(minor)) .toString(16) .padStart(8, "0") .toUpperCase() }`; }, } for (const [major, minor] of PAIRS) { const version = parseFloat(`${major}.${minor}`); const written = serdeBigint.write(version); const read = serdeBigint.read(written); if (read !== version) { throw new Error(); } }
regex + parseInt
const serde = { read(value) { let [major, minor] = value .match(/0x([0-9a-f]{4})([0-9a-f]{4})/i) .slice(1) .map(v => parseInt(v, 16)); while (minor >= 1) minor /= 10; return Math.round((major + minor) * 1e5) / 1e5; }, write(value) { let minor = Math.round((value % 1) * 1e5); const major = Math.round(value - (minor / 1e5)); while (minor && !(minor % 10)) minor /= 10; const hexify = n => n .toString(16) .padStart(4, "0") .toUpperCase(); return `0x${hexify(major)}${hexify(minor)}`; }, } for (let [major, minor] of PAIRS) { const version = parseFloat(`${major}.${minor}`); const written = serde.write(version); const read = serde.read(written); if (read !== version) { throw new Error(); } }
regex + parseInt with parseFloat(template)
const serde = { read(value) { const [major, minor] = value .match(/0x([0-9a-f]{4})([0-9a-f]{4})/i) .slice(1) .map(v => parseInt(v, 16)); return parseFloat(`${major}.${minor}`); }, write(value) { let minor = Math.round((value % 1) * 1e5); const major = Math.round(value - (minor / 1e5)); while (minor && !(minor % 10)) minor /= 10; const hexify = n => n .toString(16) .padStart(4, "0") .toUpperCase(); return `0x${hexify(major)}${hexify(minor)}`; }, } for (let [major, minor] of PAIRS) { const version = parseFloat(`${major}.${minor}`); const written = serde.write(version); const read = serde.read(written); if (read !== version) { throw new Error(); } }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
BigInt
regex + parseInt
regex + parseInt with parseFloat(template)

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):

LLMs can make mistakes. Check important info.

I'll break down the benchmark and its options, pros, cons, and other considerations.

**Benchmark Definition**

The benchmark measures the performance of three different approaches to parse 32-bit hex strings into BigInt values:

1. `BigInt`: uses a custom serializer and deserializer implementation for BigInt.
2. `regex + parseInt`: uses regular expressions and `parseInt` to parse the hex string.
3. `regex + parseInt with parseFloat(template)`: uses regular expressions, `parseInt`, and a template literal to parse the hex string.

**Options Compared**

The three options are compared in terms of their execution speed, which is measured by the number of executions per second (ExecutionsPerSecond).

**Pros and Cons of Each Option**

1. **BigInt**:
	* Pros: designed specifically for BigInt parsing, potentially more efficient due to optimized implementation.
	* Cons: may require additional setup or understanding of the serializer and deserializer implementation.
2. **regex + parseInt**:
	* Pros: widely supported and easy to implement, can be efficient for simple parsing cases.
	* Cons: may be slower than custom implementations like BigInt, prone to errors due to regex complexity.
3. **regex + parseInt with parseFloat(template)**:
	* Pros: combines the benefits of regular expressions and template literals, potentially more readable and maintainable code.
	* Cons: may add overhead due to template literal creation, still relies on `parseInt` which can be slower.

**Library Used**

The `serdeBigint` library is used in the `BigInt` option. It provides a custom serializer and deserializer implementation for BigInt values, which are designed to handle 32-bit hex strings efficiently.

**Special JS Feature/Syntax**

None of the options rely on special JavaScript features or syntax beyond regular expressions and template literals.

**Other Considerations**

The benchmark results show that:

* `regex + parseInt` is the fastest option, with an average execution speed of around 869 executions per second.
* `regex + parseInt with parseFloat(template)` is slightly slower than `regex + parseInt`, but still relatively fast.
* `BigInt` is the slowest option, with an average execution speed of around 582 executions per second.

Overall, the choice of parsing approach depends on the specific use case and performance requirements. If simplicity and wide compatibility are prioritized, `regex + parseInt` may be the best choice. However, if high performance and customizability are required, `BigInt` or a similar custom implementation might be more suitable.

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

Browser/OS: Chrome 103 on Windows

View result in a separate tab

Test name	Executions per second
BigInt	583.0 Ops/sec
regex + parseInt	869.5 Ops/sec
regex + parseInt with parseFloat(template)	845.7 Ops/sec

Related benchmarks:

Parse 32-bit hex | BigInt vs regex + parseInt (version: 0)

Comparing performance of: BigInt vs regex + parseInt vs regex + parseInt with parseFloat(template)

Created: 2 years ago by: Guest

Jump to the latest result

BigInt

regex + parseInt

regex + parseInt with parseFloat(template)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):