Benchmark: hashin' nums: .call(n) vs (n)

HTML Preparation code:

<script>
'use strict';

const float64 = (a, b) => {
	let x = new Uint32Array(2);
	let y = new Float64Array(x.buffer);
	x[0] = a|0;
	x[1] = b|0;
	return y[0];
};

const float32 = (a) => {
	let x = new Uint32Array(1);
	let y = new Float64Array(x.buffer);
	x[0] = a|0;
	return y[0];
};

const floatParts = (n) => {
	let x = new Uint32Array(2);
	let y = new Float64Array(x.buffer);
	y[0] = n;
	return [...x];
};

const randNum = () =>
	float64(
		(Math.random() * 0xffffffff)|0,
		(Math.random() * 0xffffffff)|0);

const randSpecial = () =>
	float64(
		(Math.random() * 0xffffffff)|0,
		(Math.random() * 0xffffffff)|0b01111111111100000000000000000000);

const nums = [...Array(5000)]
	.map(randNum)
	.concat([NaN, Infinity, -Infinity, -0, +0]);

// -----------------------------------------
  
const u32s = new Uint32Array(2);
const f64s = new Float64Array(u32s.buffer);

const numberHash1 = function() {
  'use strict';
	f64s[0] = this;

	f64s[0] = f64s[0];
	return u32s[0] ^ u32s[1];
};

const numberHash2 = function(n) {
  'use strict';
	f64s[0] = n;

	f64s[0] = f64s[0];
	return u32s[0] ^ u32s[1];
};
  
</script>

Tests:

h1
let sum = 0; for (let i = 0, len = nums.length; i < len; ++i) { sum += numberHash1.call(nums[i]); };
h2
let sum = 0; for (let i = 0, len = nums.length; i < len; ++i) { sum += numberHash2(nums[i]); };

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
h1
h2

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Measuring JavaScript performance is a fascinating topic!

Let's break down the provided benchmark definition and test cases to understand what's being tested.

**Benchmark Definition:**
The script preparation code defines several functions:

* `float64`: takes two 32-bit integers, converts them to Float64 arrays, and returns their sum.
* `float32`: takes a single 32-bit integer, converts it to a Float64 array, and returns its value (which is the same as the input due to floating-point representation limitations).
* `floatParts`: splits a 64-bit float into two 32-bit integers using the IEEE 754 format.

These functions are used in the test cases to generate random numbers (`randNum` and `randSpecial`) and calculate hashes (`numberHash1` and `numberHash2`).

**Individual Test Cases:**

1. **h1**: The benchmark definition uses `numberHash1.call(nums[i])`, which calls the `call` method on the `this` context of the function, passing `nums[i]` as an argument. This creates a new scope with `this` bound to the `numberHash1` function.
2. **h2**: The benchmark definition uses `numberHash2(nums[i])`, which does not use the `call` method. Instead, it directly calls the `numberHash2` function on the global object (which is assumed to be `window` or `global` in a browser environment), passing `nums[i]` as an argument.

**Options compared:**
The two test cases compare the performance of calling the `call` method versus not using it. The `call` method creates a new scope with `this` bound to the function, while omitting it uses the global object as the context for the function call.

**Pros and Cons:**

* **Using `call`:**
	+ Pros:
		- Can be useful when you want to create a closure or modify the behavior of a function.
		- Can help with function overloading or polymorphism.
	+ Cons:
		- Creates a new scope, which can lead to performance overhead due to creation and garbage collection of objects.
* **Not using `call`:**
	+ Pros:
		- Avoids creating a new scope, reducing overhead.
		- Can be faster for simple function calls with no closure or context changes.
	+ Cons:
		- May lead to less predictable behavior if the global object's context is modified unexpectedly.

**Other Considerations:**

* The use of floating-point arithmetic and the specific IEEE 754 format used in `float64` and `floatParts` may introduce performance variations depending on the browser or platform.
* The test uses a large array of random numbers (`nums`) to simulate a high-performance workload. This might not be representative of typical real-world scenarios.

**Alternatives:**

If you're interested in exploring other benchmarking approaches, here are some alternatives:

1. **Benchmarking with `this` and no `call`:** Instead of using the `call` method, you can define the functions on a specific object or create a new scope without it.
2. **Using `bind()` instead of `call`:** The `bind()` method creates a new scope with `this` bound to an argument, similar to `call`. However, it might be slightly more efficient due to its optimized implementation.
3. **Using `let` and `const` instead of global variables:** Using local variables can reduce memory allocation overhead and improve performance in some cases.

Keep in mind that these alternatives might not provide significant differences in most scenarios, but they can be worth exploring if you're looking for edge cases or specific use cases where performance is critical.

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0.1 Waterfox/56.0.1

Browser/OS: Firefox 56 on Windows 7

View result in a separate tab

Test name	Executions per second
h1	26306.9 Ops/sec
h2	26662.4 Ops/sec

Related benchmarks:

hashin' nums: .call(n) vs (n) (version: 0)

Comparing performance of: h1 vs h2

Created: 6 years ago by: Registered User

Jump to the latest result

h1

h2

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):