Benchmark: parseInt vs toFixed vs ~~

HTML Preparation code:

<div id="num"></div>

Script Preparation code:

var el = document.getElementById('num');

Tests:

parseInt
var decimal = 30.0; for (var i = 0; i < 10000; i++) { decimal += (i / 1000); el.innerHTML = parseInt(decimal, 10); }
toFixed
var decimal = 30.0; for (var i = 0; i < 10000; i++) { decimal += (i / 1000); el.innerHTML = decimal.toFixed(); }
~~
var decimal = 30.0; for (var i = 0; i < 10000; i++) { decimal += (i / 1000); el.innerHTML = ~~decimal; }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
parseInt
toFixed
~~

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Let's break down what's being tested in the provided benchmark.

The benchmark is designed to compare the performance of three different methods for formatting numbers:

1. `parseInt`: converting a number string to an integer
2. `toFixed`: rounding a number to a fixed decimal place
3. `~~`: the bitwise NOT operator, which can be used to truncate a number (e.g., `-5 ~~ 10` is equivalent to `-5`)

The test cases are simple:

* The initial value of a decimal number is set to 30.0.
* A loop runs 10,000 times, adding a fraction to the decimal value and then updating an HTML element with the result.

Now, let's discuss the pros and cons of each approach:

**parseInt**

Pros: Fast, lightweight, and widely supported.

Cons: Can be brittle if the input string is not in the expected format. If the first character is not a digit, `parseInt` will return 0, which might not be what you want.

**toFixed**

Pros: More flexible than `parseInt`, as it can handle a wider range of input formats. It's also more readable and easier to understand.

Cons: Can be slower than `parseInt`, especially for large numbers or decimal places.

**~~**

Pros: Very lightweight, as it only requires a single operation (bitwise NOT).

Cons: Can be tricky to read and understand, especially if you're not familiar with the bitwise NOT operator. It can also produce unexpected results if the input value is negative or zero.

In terms of performance, the `~~` approach tends to be the fastest, followed closely by `parseInt`, and then `toFixed`. However, the difference between these methods might not be significant for most use cases.

As for the libraries used in this benchmark, none are explicitly mentioned. However, it's worth noting that some modern browsers have built-in functions like `Number.prototype.toFixed()` and `parseInt()` with support for decimal places.

There are other alternatives to these three approaches:

* **toString() + parseInt()**: This approach can be useful if you need more control over the output format.
* **Math.round()`: Similar to `toFixed`, but without the precision control. It's also faster than `toFixed` but might not produce the same results for all edge cases.
* **Decimal libraries**: If you need precise decimal arithmetic, a dedicated library like Decimal.js can provide more accurate and flexible calculations.

Keep in mind that these alternatives come with their own trade-offs and potential performance impacts.

I hope this explanation helps!

Latest run results:

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

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

Browser/OS: Chrome 128 on Windows

View result in a separate tab

Test name	Executions per second
parseInt	112.6 Ops/sec
toFixed	103.5 Ops/sec
~~	132.9 Ops/sec

Related benchmarks:

parseInt vs toFixed vs ~~ (version: 0)

Comparing performance of: parseInt vs toFixed vs ~~

Created: 4 years ago by: Guest

Jump to the latest result

parseInt

toFixed

~~

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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