Benchmark: js private field

Tests:

private
class MyClass { #_propertyOne = 1; #_propertyTwo = 2; #_sum = 0; sumProperties() { for (let i = 0; i < 10_000; i++) this.#_sum += this.#_propertyOne + this.#_propertyTwo; } } new MyClass().sumProperties();
public
class MyClass { _propertyOne = 1; _propertyTwo = 2; _sum = 0; sumProperties() { for (let i = 0; i < 10_000; i++) this._sum += this._propertyOne + this._propertyTwo; } } new MyClass().sumProperties();

Historical Performance Data aggregated from 35 community runs

Desktop Results:

Chrome 17 runs

public

11K/s

private

6K/s

Fastest: public (1.8x faster)

View exact numbers

✓ public: 10,775 ops/sec
• private: 6,067 ops/sec

Firefox 12 runs

public

12K/s

private

2K/s

Fastest: public (5.0x faster)

View exact numbers

✓ public: 11,752 ops/sec
• private: 2,351 ops/sec

Safari 6 runs

public

69K/s

private

2K/s

Fastest: public (28.8x faster)

View exact numbers

✓ public: 68,589 ops/sec
• private: 2,381 ops/sec

Results show median performance across all community submissions. Run this benchmark yourself to verify on your device.

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
private
public

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:152.0) Gecko/20100101 Firefox/152.0

Browser/OS: Firefox 152 on Mac OS X 10.15

View result in a separate tab

public

12K/s

private

2K/s

View exact numbers

Test name	Executions per second
✓ public	11,725 Ops/sec
private	2,360 Ops/sec

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

LLMs can make mistakes. Check important info.

**Understanding the Benchmark**

The provided benchmark measures the performance difference between two approaches to declaring properties in JavaScript classes: private and public.

In JavaScript, there is no strict enforcement of property access modifiers like `public` or `private`. Instead, developers often use conventional naming conventions (e.g., `m_` for private properties and `_` for public properties) to indicate the intended accessibility of a property. However, this convention is not enforced by the language itself.

**Private Field Approach**

The first test case uses a pseudo-private field approach, where the `_propertyOne`, `_propertyTwo`, and `_sum` fields are prefixed with an underscore (`_`) to signal that they should be treated as private. This approach relies on developer discipline and convention rather than strict enforcement by the JavaScript engine.

**Public Field Approach**

The second test case uses a pseudo-public field approach, where the `_propertyOne`, `_propertyTwo`, and `_sum` fields are not prefixed with an underscore. This approach is often used in older JavaScript versions or libraries that do not support modern JavaScript features like private fields (introduced in ECMAScript 2020).

**Comparison of Approaches**

When comparing these two approaches, we can consider the following pros and cons:

* **Private Field Approach (with `_`)**
	+ Pros:
		- Follows modern JavaScript convention
		- Can help prevent accidental or intentional property exposure
	+ Cons:
		- Requires developer discipline and adherence to naming conventions
		- May not be compatible with older JavaScript versions or libraries that do not support private fields
* **Public Field Approach (without `_`)**
	+ Pros:
		- More widely supported across different JavaScript versions and libraries
	+ Cons:
		- Lacks explicit indication of property accessibility, making it easier for developers to accidentally expose properties

**Library: `let` vs. `const`**

There is no library involved in this benchmark. However, if you're interested in exploring alternatives, consider using the `let` keyword instead of `const`. This can provide similar benefits to private fields by scoping variables and preventing accidental reassignment.

**Special JavaScript Feature: Rest Operator (Destructuring)**

There is no explicit mention of special JavaScript features like the rest operator (`...`) or destructuring in the provided benchmark. However, if you're interested in exploring these features, consider using them in your tests to further evaluate performance benefits.

**Alternative Benchmarks**

Other alternatives to measure performance differences in JavaScript include:

* Using different variable scoping techniques (e.g., `var` vs. `let` vs. `const`)
* Evaluating the impact of different data structures and algorithms on performance
* Comparing the performance of modern JavaScript features like async/await, generators, or classes against older approaches

Keep in mind that the specific characteristics and requirements of your benchmark will dictate which alternatives are most suitable for evaluation.

js private field (version: 0) Benchmark.js

Comparing performance of: `private vs public`

Created: 4 years ago by: Guest

Go to the latest result

private

public

Historical Performance Data aggregated from 35 community runs

Desktop Results:

Chrome 17 runs

Firefox 12 runs

Safari 6 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

js private field (version: 0) Benchmark.js

Comparing performance of: private vs public

Created: 4 years ago by: Guest

Go to the latest result

private

public

Historical Performance Data aggregated from 35 community runs

Desktop Results:

Chrome 17 runs

Firefox 12 runs

Safari 6 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

Related benchmarks

Comparing performance of: `private vs public`