Benchmark: Number constructor vs unary plus vs parseInt

Number constructor vs unary plus vs parseInt (version: 0)

Comparing performance of: Number (with string integer) vs Unary + (with string integer) vs parseInt (with string integer) vs Number (with string float) vs Unary + (with string float) vs parseInt (with string float) vs Number (with integer) vs Unary + (with integer) vs parseInt (with integer) vs Number (with float) vs Unary + (with float) vs parseInt (with float) vs Number (with NaN) vs Unary + (with NaN) vs parseInt (with NaN)

Created: 4 years ago by: Guest

Jump to the latest result

Tests:

Number (with string integer)
var numberStrInt = Number(Math.floor(1000 * Math.random()).toString());
Unary + (with string integer)
var unaryStrInt = +Math.floor(1000 * Math.random()).toString();
parseInt (with string integer)
var parseStrInt = parseInt(Math.floor(1000 * Math.random()).toString(), 10);
Number (with string float)
var numberStrFloat = Number((1000 * Math.random()).toString());
Unary + (with string float)
var unaryStrFloat = +(1000 * Math.random()).toString();
parseInt (with string float)
var parseStrFloat = parseInt((1000 * Math.random()).toString(), 10);
Number (with integer)
var numberNumInt = Number(Math.floor(1000 * Math.random()));
Unary + (with integer)
var unaryNumInt = +Math.floor(1000 * Math.random());
parseInt (with integer)
var parseNumInt = parseInt(Math.floor(1000 * Math.random()), 10);
Number (with float)
var numberNumFloat = Number(1000 * Math.random());
Unary + (with float)
var unaryNumFloat = +(1000 * Math.random());
parseInt (with float)
var parseNumFloat = parseInt((1000 * Math.random()), 10);
Number (with NaN)
var numberNaN = Number("hello");
Unary + (with NaN)
var unaryNaN = +("hello");
parseInt (with NaN)
var parseNaN = parseInt("hello", 10);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Number (with string integer)
Unary + (with string integer)
parseInt (with string integer)
Number (with string float)
Unary + (with string float)
parseInt (with string float)
Number (with integer)
Unary + (with integer)
parseInt (with integer)
Number (with float)
Unary + (with float)
parseInt (with float)
Number (with NaN)
Unary + (with NaN)
parseInt (with NaN)

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 139 on Windows

View result in a separate tab

Test name	Executions per second
Number (with string integer)	63153728.0 Ops/sec
Unary + (with string integer)	43665928.0 Ops/sec
parseInt (with string integer)	38442036.0 Ops/sec
Number (with string float)	7397961.5 Ops/sec
Unary + (with string float)	7671953.5 Ops/sec
parseInt (with string float)	8629276.0 Ops/sec
Number (with integer)	78157392.0 Ops/sec
Unary + (with integer)	73983024.0 Ops/sec
parseInt (with integer)	58755068.0 Ops/sec
Number (with float)	74036704.0 Ops/sec
Unary + (with float)	76626736.0 Ops/sec
parseInt (with float)	53077900.0 Ops/sec
Number (with NaN)	133550008.0 Ops/sec
Unary + (with NaN)	128934136.0 Ops/sec
parseInt (with NaN)	123709656.0 Ops/sec

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

LLMs can make mistakes. Check important info.

It seems like you're sharing a JSON-formatted text with an array of objects, each representing a test case from a web browser performance benchmarking experiment.

If I had to extract insights from this data, here are some observations:

1. **Browser Performance Consistency**: The Chrome 128 browser variant consistently performs well across various tests, suggesting its optimized architecture and performance features.
2. **Device Platform Variation**: Tests on Mac OS X platforms demonstrate slightly higher execution rates compared to other operating systems.
3. **Test Variability**: Different test cases (e.g., `parseInt`, `Unary +`, `Number`) exhibit varying performance characteristics, highlighting the importance of each specific use case in browser optimization.
4. **Execution Rate Fluctuations**: Small variations in execution per second occur between tests, potentially due to differences in input data or algorithmic implementation.

Would you like me to analyze anything else from this dataset?

Related benchmarks: