Benchmark: * 10, round vs trunc vs floor vs parseFloat vs ~~ vs 0 | vs parseInt vs parseInt, 10

Tests:

trunc
const x = Math.trunc(12.34 * 10); const y = Math.trunc(567.89 * 10);
round
const x = Math.round(12.34 * 10); const y = Math.round(567.89 * 10);
floor
const x = Math.floor(12.34 * 10); const y = Math.floor(567.89 * 10);
parseFloat to int
const x = parseFloat((12.34 * 10).toFixed()); const y = parseFloat((567.89 * 10).toFixed());
~~
const x = ~~(12.34 * 10); const y = ~~(567.89 * 10);
0 |
const x = (0 | 12.34 * 10); const y = (0 | 567.89 * 10);
parseInt
const x = parseInt(12.34 * 10); const y = parseInt(567.89 * 10);
parseInt, 10
const x = parseInt(12.34 * 10, 10); const y = parseInt(567.89 * 10, 10);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
trunc
round
floor
parseFloat to int
~~
0 \|
parseInt
parseInt, 10

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 122 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
trunc	7436124.5 Ops/sec
round	7450237.0 Ops/sec
floor	7451651.5 Ops/sec
parseFloat to int	2929326.5 Ops/sec
~~	160367520.0 Ops/sec
0 \|	154319904.0 Ops/sec
parseInt	7348802.5 Ops/sec
parseInt, 10	7398285.0 Ops/sec

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

LLMs can make mistakes. Check important info.

Measuring JavaScript performance is crucial for optimizing code and ensuring it runs efficiently across various browsers and environments.

Let's break down the provided JSON and analyze each test case:

**Benchmark Definition**

The benchmark compares different methods to convert a floating-point number to an integer, including multiplication by 10. The methods being compared are:

1. `Math.trunc()`
2. `Math.round()`
3. `Math.floor()`
4. `parseFloat()` with `toFixed()` for conversion
5. `~~` (bitwise NOT)
6. `(0 | ...)` (bitwise OR with 0)
7. `parseInt()` and `parseInt()` with a radix of 10

**Options Compared**

Here's a brief explanation of each method:

1. **Math.trunc()**: Returns the largest possible integer less than or equal to the given number. It's similar to `Math.floor()`, but avoids rounding errors.
2. **Math.round()**: Rounds the given number to the nearest integer, either up or down, depending on the fractional part.
3. **Math.floor()**: Returns the largest possible integer less than or equal to the given number.
4. **parseFloat()` with `toFixed()` for conversion**: Converts a floating-point number to an integer by extracting the integer part from the `toFixed()` result.
5. **~~ (bitwise NOT)**: This is not a standard JavaScript operator, but rather a Microsoft-specific extension. It performs a bitwise NOT operation on the given number, effectively rounding down to the nearest integer.
6. `(0 | ...)` (bitwise OR with 0): This is another non-standard JavaScript construct. When applied to a number `x`, it returns `-x` if `x` is negative and `x` otherwise.
7. **parseInt()**: Parses a string or an integer string representation of the given value, returning the resulting integer.
8. **parseInt()` with radix 10**: Similar to the previous one, but specifies that the input should be treated as an octal number.

**Pros and Cons**

Here's a brief summary of each method:

1. `Math.trunc()`:
	* Pros: Fast, simple, and reliable.
	* Cons: May lose precision for very large or small numbers.
2. `Math.round()`: 
	* Pros: Versatile, handles both positive and negative numbers.
	* Cons: Can lead to rounding errors, especially when dealing with very large or small numbers.
3. `Math.floor()`:
	* Pros: Similar to `Math.trunc()`, fast, and reliable.
	* Cons: May lose precision for some edge cases.
4. **parseFloat()` with `toFixed()`**:
	* Pros: Simple, handles both positive and negative numbers.
	* Cons: Can lead to rounding errors due to the conversion process.
5. `~~ (bitwise NOT)`:
	* Pros: Fast, simple, and reliable in Microsoft environments.
	* Cons: Not a standard JavaScript operator, may not work as expected in other browsers or environments.
6. `(0 | ...)` (bitwise OR with 0):
	* Pros: Simple, handles both positive and negative numbers.
	* Cons: Non-standard, may not work as expected in other browsers or environments.
7. **parseInt()**:
	* Pros: Handles both string and integer inputs, reliable in many cases.
	* Cons: May lead to errors if the input is not a valid number or has an invalid radix.
8. **parseInt()` with radix 10**:
	* Pros: Similar to `parseInt()`, but ensures octal numbers are treated correctly.
	* Cons: Not as versatile as standard `parseInt()`.

**Results**

The benchmark results show that each method performs differently depending on the browser and environment used. However, in general:

1. `Math.trunc()` and `Math.floor()` tend to be faster and more reliable than other methods.
2. `Math.round()` can lead to rounding errors, especially for very large or small numbers.
3. `~~ (bitwise NOT)` is a good alternative to `Math.trunc()`, but its non-standard status may cause issues in some environments.
4. `(0 | ...)` (bitwise OR with 0) is an interesting approach that can produce unexpected results, especially for negative numbers.

Overall, the choice of method depends on the specific requirements and constraints of your project. If you need a simple, fast, and reliable solution, `Math.trunc()` or `Math.floor()` might be the best option. However, if you're working with strings or want to handle edge cases more robustly, consider using `parseInt()`.

Related benchmarks:

* 10, round vs trunc vs floor vs parseFloat vs ~~ vs 0 | vs parseInt vs parseInt, 10 (version: 0)

fastest from float to int with multiplication

Comparing performance of: trunc vs round vs floor vs parseFloat to int vs ~~ vs 0 | vs parseInt vs parseInt, 10

Created: 11 months ago by: Guest

Jump to the latest result

trunc

round

floor

parseFloat to int

~~

0 |

parseInt

parseInt, 10

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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