Tabling NPM | npm.io

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

⚙️ Install

npm add tabling

🚀 Usage

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.

🔎 API

Module: `tabling`

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.

Module: `tabling/warm`

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

Upfront cost, but no read time.

🤔 But which one should I use?

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

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.
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

💨 Benchmark

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.