tabling

npm add tabling makes objects lazy

Commit a getter's result for one-time evaluation.

npm add tabling

import { tabling } from "tabling";

const myObject = tabling({
	get answer() {
		return discover_the_meaning_of_life();
	},
});

myObject.answer; // 42

Where ordinarily, that would look like { answer: discover_the_meaning_of_life() } for a value somebody may never read.

The main and default module and us Proxy based. Everything is lazy here, the object is built-up over which keys are consumed.

No upfront cost, and slightly slower read time.

A object based implementation, whereby the result is setup at evaluation time.

Upfront cost, but no read time.

Naturally riddled with assumptions. But If you see the benchmarks below, generally the advice is.

1. if you've got a long-running process with many reads, the /warm sub-module is what youre after.
   • think like a web-server, where the object is module-scope.
2. browsers, you're probably after the default (proxy based) api. Very minimal reads, and want fast as possible startup time.

So with that, and by no means bullet-proof answer;

• server — tabling/warm
• browser - tabling

via the /bench directory with Node v17.2.0

benchmark :: setup
  default              x 2,442,456 ops/sec ±1.92% (89 runs sampled)
  warm                 x   503,581 ops/sec ±0.69% (93 runs sampled)

benchmark :: jit
  default              x   2,168,685 ops/sec ±1.25% (91 runs sampled)
  warm                 x 430,936 ops/sec ±1.49% (91 runs sampled)

benchmark :: aot
  default              x  27,579,584 ops/sec ±0.52% (89 runs sampled)
  warm                 x 133,821,620 ops/sec ±0.34% (93 runs sampled)

setup — the time to construct the object, without reading from it.

jit — the object is constructed on the hot path, and read from immediately. Think "request bound" objects.

aot — the object is constructed ahead of time, and read later on the hot path. Think "module scope" objects.

Special thanks to @wongmjane for idea!

MIT © Marais Rossouw