Benchmark: Math.floor(N) vs (N | 0) vs parseInt(N)

Script Preparation code:

var len = 10000000
var nums = Array(len)
    .fill()
    .map(() => Math.random() * 10000)

Tests:

Math.floor(N)
for (let i = 0; i < len; i++) { const result = Math.floor(nums[i]) }
(N | 0)
for (let i = 0; i < len; i++) { const result = nums[i] | 0 }
parseInt(N)
for (let i = 0; i < len; i++) { const result = parseInt(nums[i]) }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Math.floor(N)
(N \| 0)
parseInt(N)

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

**Overview of the Benchmark**

The provided benchmark measures the performance differences between three approaches to truncate negative numbers in JavaScript:

1. `Math.floor(N)`: Uses the built-in `floor` function from the Math object.
2. `(N | 0)`: Uses a bitwise OR operation with zero (`|` is the bitwise OR operator).
3. `parseInt(N)`: Uses the `parseInt` function to convert the number to an integer.

**Description of Each Approach**

### 1. `Math.floor(N)`

* This approach uses the built-in `floor` function from the Math object, which returns the largest integer less than or equal to the input value.
* The pros of this approach are:
	+ It is a standardized and well-tested function in JavaScript.
	+ It can handle negative numbers correctly without any additional checks.
* However, it may be slower than other approaches for very large integers due to its internal implementation.

### 2. `(N | 0)`

* This approach uses a bitwise OR operation with zero (`|` is the bitwise OR operator). In two's complement representation, subtracting zero from a negative number results in a positive value with the same bit pattern as the original negative number.
* The pros of this approach are:
	+ It can be faster than other approaches for very large integers because it avoids the need to perform arithmetic operations or lookups.
	+ It is often considered more readable and concise than using `Math.floor` or `parseInt`.
* However, it may not work correctly for certain edge cases (e.g., numbers with fractional part) and can be slower for small integers.

### 3. `parseInt(N)`

* This approach uses the `parseInt` function to convert the number to an integer.
* The pros of this approach are:
	+ It is a simple and efficient way to truncate negative numbers.
	+ It can handle a wide range of input values, including strings with leading zeros or non-numeric characters.
* However, it may be slower than other approaches for very large integers due to its internal implementation.

**Library Used**

None. The benchmark only uses built-in JavaScript functions and operators.

**Special JS Feature/Syntax**

None mentioned in the provided information.

**Alternatives**

If the goal is to measure the performance of integer truncation operations, alternative approaches could include:

* Using a library like `big-integer` or `decimal.js` for arbitrary-precision arithmetic.
* Implementing custom integer truncation logic using bitwise operations or assembly language.
* Using a different programming language that has built-in support for integer truncation.

However, the benchmark as provided seems to be focused on measuring the performance differences between three standard JavaScript approaches, and alternative approaches would require additional setup and configuration.

Latest run results:

Run details: (Test run date: 4 months ago)

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

Browser/OS: Chrome 126 on Windows

View result in a separate tab

Test name	Executions per second
Math.floor(N)	0.9 Ops/sec
(N \| 0)	1.7 Ops/sec
parseInt(N)	0.9 Ops/sec

Related benchmarks:

Math.floor(N) vs (N | 0) vs parseInt(N) (version: 0)

Comparing performance of: Math.floor(N) vs (N | 0) vs parseInt(N)

Created: 5 months ago by: Guest

Jump to the latest result

Math.floor(N)

(N | 0)

parseInt(N)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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