Benchmark: ref?.current? vs ref.current?

Script Preparation code:

var _a$current; 
var a = {  current: function () {} };

Tests:

a?.current?.();
a === null || a === void 0 || (_a$current = a.current) === null || _a$current === void 0 ? void 0 : _a$current.call(a);
a.current?.();
(_a$current = a.current) === null || _a$current === void 0 ? void 0 : _a$current.call(a);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
a?.current?.();
a.current?.();

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

I'd be happy to explain what's being tested in the provided benchmark.

**What is being tested?**

MeasureThat.net is testing two different ways of calling the `current` method on an object `a`. The object `a` has a `current` method defined, but it's not immediately clear whether this method is guaranteed to exist or return a value when called.

The test cases are comparing two approaches:

1. `a.current?.();`
2. `(_a$current = a.current) === null || _a_current !== void 0 ? _a_current.call(a);`

**Options being compared**

In the first approach, `a.current?.();`, the dot notation `.` is used to call the method, and the optional chaining operator (`?.`) is used to check if the property exists before attempting to access it. If the property does not exist, the expression will return `undefined`.

In the second approach, `(_a$current = a.current) === null || _a_current !== void 0 ? _a_current.call(a);`, a variable `_a$current` is declared and assigned the value of `a.current`. The expression then checks if this variable is null or undefined using the OR operator (`||`). If it's not null or undefined, the function call `_a_current.call(a)` is executed.

**Pros and cons of each approach**

1. **Optional chaining (`?.`):**
	* Pros:
		+ More concise and readable syntax
		+ Reduces the risk of null pointer exceptions
	* Cons:
		+ May not work as expected in older browsers that don't support optional chaining
2. **Explicit variable declaration and function call:**
	* Pros:
		+ More control over the evaluation order (i.e., it's harder to accidentally skip the function call)
		+ Works in older browsers that don't support optional chaining
	* Cons:
		+ Less concise and less readable syntax
		+ Requires more code, which can increase maintenance costs

**Library usage**

None of the test cases use any external libraries.

**Special JS feature or syntax**

The test case uses the optional chaining operator (`?.`) to check if a property exists before attempting to access it. This is a relatively new feature introduced in ECMAScript 2020 (ES11). If you're targeting older browsers that don't support this operator, you can replace it with other techniques, such as using `in` and `typeof` or using a library like Lodash.

**Other alternatives**

If you want to compare these approaches without relying on the optional chaining operator, you could use:

* Checking if the property exists using `in` and then calling the method
```javascript
a.current && a.current();
```
* Using a library like Lodash, which provides a more robust way of handling null or undefined values
```javascript
import _ from 'lodash';
_.defaults(a, { current: function () {} });
a.current();
```

Keep in mind that these alternatives may have different performance characteristics and may not be as concise or readable as the original approaches.

Latest run results:

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

User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Browser/OS: Chrome 119 on Linux

View result in a separate tab

Test name	Executions per second
a?.current?.();	3121737.5 Ops/sec
a.current?.();	4220471.5 Ops/sec

Related benchmarks:

ref?.current? vs ref.current? (version: 0)

Comparing performance of: a?.current?.(); vs a.current?.();

Created: one year ago by: Guest

Jump to the latest result

a?.current?.();

a.current?.();

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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