Hi!

This morning I was designing a fast object cache for DCP's new proxy key authentication feature, which left me curious about the fastest way to detect the existence of an Object property in our environment. We are currently running Node.js version 12-LTS; my workstation is equipped with v12.21.0, which uses version 7.8.279.23 of Google's v8 JavaScript engine.

I sat down and thought about this problem for a few minutes, and could think of 5 decent ways to do this.

1. `if (testObject.hasOwnProperty(propName))`: this method checks if the property exists on the object I am testing, and does not test if it exists on the prototype chain (ie. is inherited). This is my usual "go-to" for this type of test; besides the fact that I believe it to be quite efficient, it does not yield surprising results when third-party libraries modify Object.prototype. Frameworks such as MooTools and Prototype.JS do this, or at least did in the past, so I have developed a healthy wariness around arbitrary object property tests.
2. `if (testObject[propName])`: this method checks if the property exists on the object I am testing, and also if it exists on its prototype chain. All of my objects for this cache began life as object literals, so this is an equivalent-enough test for the purposes of my cache. I know for a fact I will not have any cache keys which collide with default object property names (eg. `constructor`, `hasOwnProperty`, `__proto__`, and so on). In theory, this test will need to coerce the property object to a boolean, but I expect the JIT will be able to optimze that away for the most part -- my test is mostly for cache misses.
3. `if (propName in testObject)`: this method is similar to `hasOwnProperty` in that the engine can check for the existence of a property without coercing to boolean, but it checks both the object itself and the prototype chain, since the property could be inherited. I was hoping that this purpose-made check that was relatively new in the language would perform well, since they v8 authors would have opportunity and motivation for optimization.
4. `if (Object.hasOwnProperty.call(testObject, propName):` this is exactly the same as the first `hasOwnProperty` test, except that I have explictly identified the `hasOwnProperty` method that I want to use, rather than letting the engine look up the `hasOwnProperty` property on the object, follow the prototype chain to the Object constructor, find the inherited `hasOwnProperty`, and use that. My test does not mutate the object nor its prototype chain in the hot loop, so I am hoping that the JIT is smart enough that this test and the other `hasOwnProperty` test will perform exactly the same.
5. `if (propName === undefined):` in principle, this is similar to the `in` test, except that it won't find properties whose value is `undefined` - I know I won't be caching this in my application, so that doesn't matter.

The Code

// run with  node --expose-gc

global.gc();

const performance = require('perf_hooks').performance;

var obj = {};
var tests = [];
var start, end;

function rp()
{
  return Math.random().toString(36).slice(2 + Math.random()*2);
}

for (let i=0; i < 1000; i++)
  obj[rp()] = { ran: Math.random(), now: Date.now() };

tests.push(function direct(iter, quiet) {
  start = performance.now();
  for (let i=0; i < iter; i++)
  {
    let test = rp();

    if (obj.hasOwnProperty(test))
      console.log('collision', i);
  }
  end = performance.now();
  if (!quiet)
    console.log('direct hasOwnProperty:\t', end-start);
});

tests.push(function indirect(iter, quiet) {
  start = performance.now();
  for (let i=0; i < iter; i++)
  {
    let test = rp();
    
    if (Object.hasOwnProperty.call(obj, 'test'))
      console.log('collision', i);
  }
  end = performance.now();
  if (!quiet)
    console.log('indirect hasOwnProperty:', end-start);
});

tests.push(function falsey(iter, quiet) {
  start = performance.now();
  for (let i=0; i < iter; i++)
  {
    let test = rp();
    
    if (obj[test])
      console.log('collision', i);
  }
  end = performance.now();
  if (!quiet)
    console.log('falsey:\t\t\t', end-start);
});


tests.push(function undef(iter, quiet) {
  start = performance.now();
  for (let i=0; i < iter; i++)
  {
    let test = rp();
    
    if (obj[test] !== undefined)
      console.log('collision', i);
  }
  end = performance.now();
  if (!quiet)
    console.log('undef compare:\t\t', end-start);
});

tests.push(function has(iter, quiet) {
  start = performance.now();
  for (let i=0; i < iter; i++)
  {
    let test = rp();
    
    if (test in obj)
      console.log('collision', i);
  }
  end = performance.now();
  if (!quiet)
    console.log('has:\t\t\t', end-start);
});

for (let test of tests)
  test.ran = Math.random();
tests.sort((a,b) => a.ran - b.ran);

for (let warmup of tests)
  warmup(1000, true);
for (let test of tests)
{
  global.gc();
  for (let warmup of tests)
    warmup(1000, true);
  test(1000, true);
  test(1000000, false);
}

Findings

tldr; - no real surprises.

I was disappointed to discover that `Object.hasOwnProperty.call` performs measurably better than `testObject.hasOwnProperty`, even after a million runs. I was also disappointed that `in` didn't really perform any better than its more naive counterparts. The time disparity between the two `hasOwnProperty` tests can probably be chalked up the cost to walk up the prototype chain, needed to figure out which function should be called (why can't JIT cache this?). The naive check which involve potential coercion have the worst performance, and this is probably due to the coercion actually happening. The performance of the `in` test is a bit puzzling; we know that the prototype chain traversal isn't too expensive; perhaps we are looking at the cost to traverse the chain and perform a `hasOwnProperty`-style lookup on each node until we hit end of the chain?

Q: Which style of lookup should I use in day-to-day code?
A: Whichever makes your code easiest to read.

Apologies for the lack of updates; I assumed the CTO role at KDS last summer, and have been extremely busy since then!

2020 is shaping up to be a landmark year for Kings Distributed Systems. We are currently preparing our "First Dev" milestone for release this month. This milestone gives a stable software API for use by outside developers on browser or NodeJS platforms that will allow early adopters to build software that is expected to continue to work unchanged as we add features and march down our roadmap.

Last month, in concert with CENGN (the Center for Excellence in Next Generation Computing), KDS successfully performed a 10,000-slice job modelling Tick-Borned Encephalitis across 504 core. The at-scale testing was performed largely using workers which are part of official standalone-worker package for Debian Linux (see: https://docs.distributed.computer/worker/readme.html).

• https://people.kingsds.network/wesgarland/DCL presentation - St. Lawrence