Fabio Spampinato fabiospampinato

These are some notes on the performance work that went into alien-signals. I'm sharing them not as a definitive guide, but as a log of a few key discoveries. The hope is that some of these findings might be useful to others tackling similar problems in high-performance JavaScript.

The Origin: Push-Pull-Push

My journey into the depths of reactivity performance began with Vue. I was trying to solve a specific problem in Vue 3.4: even if a computed's value didn't change, it would still trigger downstream computations and effects. This seemed inefficient. My attempt to fix this resulted in a pull request (vuejs/core#5912) that, after a year of discussions, was eventually merged. This PR introduced the Push-Pull-Push model to Vue 3.4, a model also adopted by libraries like reactivity.

For a time, I thought this was near-perfect. Then I saw the plans for Vue 3.5, which adopted a doubly-linked list but also moved to a pure pull-based model. I was still convinced

JavaScript LRU library benchmark

There are too many LRU(Least Recently Used) implementations in JS.

I recommend to use [flru] which is the smallest one and fast enough. Unless you need more rich functionality.

However, it's performance is vary depend on the host environment. For example, flru loses on Bun.

If you need micro-optimization on it, measure it yourself in your environment.

Optional chaining assignment proposal

Basically, allow this:

foo?.bar = value;

which is equivalent to

foo == null ? undefined : (foo.bar = value);

npm uses Semantic Versioning

npm uses Semantic Versioning. Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format, e.g. 1.0.0-alpha.

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

Use ESM yourself. (preferred)
Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
Stay on the existing version of the package until you can move to ESM.

Notable in Docker with network access disabled

This is not perfect but it works. Useful repo: https://github.com/jessfraz/dockerfiles

Required files

Notable deb file is available on https://notable.app/#download
.notable.json: https://gist.github.com/marcan2020/ee64d23fab07336798821139cbac221f
chrome.json: https://github.com/jessfraz/dotfiles/blob/master/etc/docker/seccomp/chrome.json

FFlate is the fastest, smallest, and most effective JavaScript compressor/decompressor currently; to create it, I used a variety of modified or optimized algorithms.

Part 1: The DEFLATE spec

The core of most popular compressed file formats is DEFLATE, or RFC1951. GZIP data, Zlib data, .zip files, PNG images, and more all use some variant of DEFLATE under the hood. At its core, the DEFLATE format is actually not too complex: it's merely a combination of Huffman coding and LZ77 compression.

If you don't understand either of these concepts, feel free to read the following subsections, or skip to Part 2 if you already know what these are and just want to get to implementation details.

Section I: Huffman Coding

Computers think of basically everything as numbers. The smallest unit of information in a computer is a single bit, which can only be either a 0 or a 1. When multiple bits are stringed together, they can be interpreted as a ba

This gist lists challenges you run into when building offline-first applications based on IndexedDB, including open-source libraries like Firebase, pouchdb and AWS amplify (more).

Note that some of the following issues affect only Safari. Out of the major browsers, Chrome's IndexedDB implementation is the best.

Backing file on disk (WAL file) keeps growing (Safari)

When this bug occurs, every time you use the indexeddb, the WAL file grows. Garbage collection doesn't seem to be working, so after a while, you end up with gigabytes of data.

	./linelen_hist.sh src '*.c'
	COLS COUNT
	2 1317 ████████████████████████████████████████████████████████████▌
	4 583 ██████████████████████████▏
	6 500 ██████████████████████▎
	8 253 ███████████▊
	10 264 ████████████▊
	12 448 ████████████████████▋
	14 417 ███████████████████▌
	16 476 █████████████████████▍

	# This example uses M2M-100 models converted to the CTranslate2 format.
	# Download CTranslate2 models:
	# • M2M-100 418M-parameter model: https://bit.ly/33fM1AO
	# • M2M-100 1.2B-parameter model: https://bit.ly/3GYiaed


	import ctranslate2
	import sentencepiece as spm