Benchmark: undefined vs. typeof vs. in vs. hasOwnProperty big object

Script Preparation code:

var obj = { a: 1, b: 2, c: 3, d: 4, e: 5,  e1: 5, e2: 5, e3: 5, e4: 5, e5: 5, e6: 5, e7: 5, e8: 5, e9: 5, e0: 5, ea: 5, eb: 5, ec: 5, ed: 5, ee: 5, ef: 5, eg: 5, eh: 5, ei: 5, ej: 5, ek: 5, el: 5, em: 5, en: 5, eo: 5, ep: 5, eq: 5, er: 5, es: 5, et: 5, eu: 5, ev: 5, ew: 5, ex: 5, ey: 5, ez: 5, f1: 5, f2: 5, f3: 5, f4: 5, f5: 5, f6: 5, f7: 5, f8: 5, f9: 5, f0: 5, fa: 5, fb: 5, fc: 5, fd: 5, fe: 5, ff: 5, fg: 5, fh: 5, fi: 5, fj: 5, fk: 5, fl: 5, fm: 5, fn: 5, fo: 5, fp: 5, fq: 5, fr: 5, fs: 5, ft: 5, fu: 5, fv: 5, fw: 5, fx: 5, fy: 5, fz: 5, g1: 5, g2: 5, g3: 5, g4: 5, g5: 5, g6: 5, g7: 5, g8: 5, g9: 5, g0: 5, ga: 5, gb: 5, gc: 5, gd: 5, ge: 5, gf: 5, gg: 5, gh: 5, gi: 5, gj: 5, gk: 5, gl: 5, gm: 5, gn: 5, go: 5, gp: 5, gq: 5, gr: 5, gs: 5, gt: 5, gu: 5, gv: 5, gw: 5, gx: 5, gy: 5, gz: 5};

Tests:

undefined
undefined !== obj.gr;
typeof
'undefined' !== typeof obj.gr;
in
'gr' in obj;
hasOwnProperty
obj.hasOwnProperty( 'gr' );
bool
!! obj.gr;
keys
Object.keys(obj).includes('gr');

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
undefined
typeof
in
hasOwnProperty
bool
keys

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 131 on Windows

View result in a separate tab

typeof

195.6M/s

undefined

174.4M/s

bool

173.3M/s

169.0M/s

hasOwnProperty

68.2M/s

keys

7.6M/s

View exact numbers

Test name	Executions per second
✓ typeof	195,581,664 Ops/sec
undefined	174,378,128 Ops/sec
bool	173,273,216 Ops/sec
in	168,991,200 Ops/sec
hasOwnProperty	68,192,568 Ops/sec
keys	7,644,506 Ops/sec

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

LLMs can make mistakes. Check important info.

I'd be happy to explain the provided benchmark and its test cases.

**Benchmark Purpose:**
The purpose of this benchmark is to compare the performance of different ways to check if an object has a property named "gr". This can be useful in scenarios where you need to iterate over the properties of an object or perform other operations that depend on whether a specific property exists.

**Test Cases:**

1. **undefined !== obj.gr;**: This test checks if the expression `obj.gr` is evaluated as falsey, which means it will return true if `obj.gr` is undefined or null.
2. **'undefined' !== typeof obj.gr;**: This test uses a type check to see if `typeof obj.gr` returns "undefined", which would indicate that `obj.gr` does not exist.
3. **'gr' in obj;**: This test uses the "in" operator to check if the property "gr" exists in the object `obj`.
4. **obj.hasOwnProperty( 'gr' );**: This test checks if the property "gr" is directly accessible on the `obj` object using its own hasOwnProperty method.
5. **!! obj.gr;**: This test uses a boolean cast to convert the value of `obj.gr` to a boolean, which will be true if it exists and false otherwise.
6. **Object.keys(obj).includes('gr');**: This test checks if the string "gr" is present in an array of object keys using the includes method.

**Performance Comparison:**

The benchmark compares the performance of each test case under different conditions. The results show that:

* `in` and `hasOwnProperty` are generally faster than type checks like `typeof`.
* Type checks can be fast if the property exists, but slower if it doesn't.
* Boolean casting (`!! obj.gr;`) is relatively slow compared to other methods.
* Using an array of object keys (`Object.keys(obj).includes('gr');`) is one of the slower methods.

**Interpretation:**
These results indicate that when checking for a property's existence, it's often faster and more efficient to use the "in" operator or directly access the property using its own hasOwnProperty method. Type checks like `typeof` can be useful if you're working with a specific type system, but may incur performance overhead.

When deciding which method to use, consider the trade-offs between speed, readability, and maintainability:

* Use `in` or `hasOwnProperty` when:
	+ You need to iterate over an object's properties.
	+ You want to avoid using type checks.
* Use `typeof` when:
	+ You're working with a specific type system that requires precise type checking.
	+ You want to emphasize the intent of your code (e.g., "does this property exist?").
* Avoid using boolean casting (`!! obj.gr;`) due to its relatively slow performance.

Keep in mind that these are general guidelines, and you should profile your specific use case to determine the most efficient approach.

undefined vs. typeof vs. in vs. hasOwnProperty big object (version: 0)

Object lookup performance

Comparing performance of: `undefined vs typeof vs in vs hasOwnProperty vs bool vs keys`

Created: 7 years ago by: Guest

Go to the latest result

undefined

typeof

in

hasOwnProperty

bool

keys

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

undefined vs. typeof vs. in vs. hasOwnProperty big object (version: 0)

Object lookup performance

Comparing performance of: undefined vs typeof vs in vs hasOwnProperty vs bool vs keys

Created: 7 years ago by: Guest

Go to the latest result

undefined

typeof

in

hasOwnProperty

bool

keys

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: `undefined vs typeof vs in vs hasOwnProperty vs bool vs keys`