Search code, repositories, users, issues, pull requests...

This document goes into a rather deep comparison of Generator to other runtime type checkers, giving also a rather broad overview of related topics.

First and foremost, my sincere respect to all the tool makers, and especially to those involved in designing, implementing, testing, and documenting each and every tool I'm comparing Generator to in this post. Keep up the great work, folks!

Type checkers in this category use only the code that the JavaScript engine runs within an application. No type information is used inside of this class of libraries. Some of them use eval to turn a schema into JS code at runtime, some like zod use pure function composition.

The main reason is that Generator produces specialized code that is easy for all the modern JS engines to optimize. Each type predicate function consists of trivial instructions (like typeof x === "string" and x === "constant") that in most cases don't even call any other functions and never any external or shared functions. JIT JavaScript engines like when code types are local and when for each distinct type there is a separate small function. This helps JS engines to specialize these small functions in runtime. See this amazing article for more details on how V8 deals with polymorphic functions.

Pure runtime checkers like zod instead use function composition. In this case, basic building block functions (like hasProperty(object, propertyName)) get reused with values of different types and thus different hidden classes. This leads to frequent deoptimizations (falling back to the slower non-optimized byte code instead of the faster native code). In the most severe cases, the JIT compiler might oscillate between optimizing and then deoptimizing a code path for one type and then another, spending a lot of cycles in just compiling the code instead of actually running it.

Leave a Comment