v0.1.38327 Oct 2026·Rendering, JavaScript & JIT, Memory & reading

JavaScript ahead of the reference runtime on six of eight speed tests

A JavaScript speed release. Floati measures its script engine against the reference JavaScript runtime on eight standard workloads: a numeric loop, recursion with a counter, a bitwise hash, reading object properties, building a string, building and dropping a tree of small objects, a Map with string keys, and array callbacks. In 0.1.382 Floati was behind on all eight, on four of them by 15 to 35 times. Now it is ahead on six, by 10 to 42 percent. The changes are all in Floati's own compilers: hash loops keep their numbers as 32-bit machine integers, multiplications and recursion counters stay exact integers, strings are built in place, Map keys carry their hash, array callbacks run without making a function object, and a loop with a try block now runs compiled. Every change has a switch that turns it off, a set of edge cases checked against the reference runtime on every compiler tier, and a deliberately broken version of the change that those checks must catch. Script time on 11 real pages is unchanged, and small objects are 24 bytes lighter. Two workloads are still behind, and they share one cause: how objects are stored and freed. Floati frees an object the moment nothing uses it, which keeps memory low and pauses short, but a page that builds and drops thousands of small objects pays for each one, where a collector that only looks at survivors pays almost nothing. We built and measured a young-object area for that this week; it was slower, so it is not in this release. The next step is a compact object layout and a way for short-lived objects to die without that per-object cost.

Parity with the reference browser

74overall, as of v0.1.402

GPU / graphics acceleration65

Security architecture72

DevTools / extensions73

Web APIs / DOM surface75

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

Six of eight workloads now faster than the reference runtime

Time per workload, Floati 0.1.382, Floati 0.1.383 and the reference JavaScript runtime, same Mac, log scale

Each workload runs a small function many times and keeps the best of five timings; the chart shows the middle of three such runs for Floati 0.1.382, this release and the reference JavaScript runtime, all on the same Mac. Before this release Floati was behind on every row. Recursion with a counter went from 69.7 ms to 1.6 ms because the recursive compiler now adds a counter once after the run instead of on every call; the bitwise hash went from 71 ms to 3.9 ms because 32-bit hash arithmetic now stays in 32-bit registers, with a multiply-and-add split so the two halves run side by side; string building went from 47 ms to 1 ms because character codes are appended in place.

Workloads faster than the reference runtime0 of 8 -> 6 of 8Recursion with a counter69.7 -> 1.6 ms (reference 2.0)Bitwise hash71.2 -> 3.9 ms (reference 4.6)String building46.9 -> 1.0 ms (reference 1.7)Map with string keys55.4 -> 13.1 ms (reference 13.8)Script time, 11 real pagesunchanged (no page slower)

What is still behind, and why

Reading properties of 2,000 objects takes 4.0 ms against the reference runtime's 2.6, and building and dropping a tree of small objects 3.9 ms against 0.9. We measured where the time goes before changing anything. For object properties it is not the checks or the arithmetic: a hand-written copy of the compiled loop ran at the reference runtime's speed once each object was as small as the reference runtime's, so this release makes every small object 24 bytes smaller (a three-field object went from 112 to 88 bytes). For the tree, two thirds of the time is freeing the objects one by one. We built a young-object area where dead objects are found together in one sweep, and measured it: it was slower (4.8 to 7.3 ms), because under reference counting every dead object must still let go of what it points at. So it stays out, and the plan for the next releases is written down with these measurements.

Object properties9.3 -> 4.0 ms (reference 2.6)Building and dropping a tree of objects19.4 -> 3.9 ms (reference 0.9)A three-field object112 -> 88 bytesPeak memory, a list of 300,000 small objects116.6 -> 109.8 MB

What changed 36 changes

JavaScript & JIT	Hash loops run as 32-bit machine integers: Math.imul, shifts and rotates stay in registers (bitwise hash 73 -> 5 ms).
Rendering	One-character strings are shared instead of made afresh, and reading a character of a string by index is faster (string building 83 -> 38 ms).
Rendering	FIX: String.fromCharCode now wraps numbers like Infinity or 1e20 the way the standard says, instead of giving the last character.
JavaScript & JIT	FIX: reading a string at an index past its end now looks on String.prototype, as the standard says.
Rendering	A build of the engine that stores values the slower, reference way compiles again.
JavaScript & JIT	Recursive functions that count their calls in an outer variable run in the recursive compiler (recursion with a counter 43 -> 1.6 ms).
JavaScript & JIT	A loop that only the first compiler could take no longer blocks its function from the faster ones (tree building 397 -> 94 ms in a page).
Rendering	FIX: let, const and class at the top of a script are now unreadable before their declaration, as the standard says (they used to read as undefined).
Rendering	FIX: the same rule now holds in functions that contain a direct eval.
JavaScript & JIT	Functions with a try block no longer record type feedback no compiler reads (Map loop 507 -> 450 ms).
JavaScript & JIT	Loops with a try block, which every for...of over a Map or Set uses, now run compiled (Map loop 484 -> 253 ms).
JavaScript & JIT	String.fromCharCode runs inside compiled loops, and a loop the fast compiler refuses lets its inner loops compile on their own (string building 39 -> 4.3 ms).
JavaScript & JIT	Compiled loops read arrays made fresh on each turn directly, and write globals back in place (Object.entries loop 72 -> 41 ms).
JavaScript & JIT	Compiled code answers undefined for a missing property, a function that keeps leaving compiled code stops being recompiled, and the optimizing tier takes ?? and ?.
JavaScript & JIT	A Map or Set iterator's next is found on its prototype, and the loop compiler takes const and let for...of loops.
JavaScript & JIT	Methods read through an object's own prototype are cached in compiled code.
JavaScript & JIT	FIX: a loop that calls a method which is later redefined as a getter now calls the getter.
JavaScript & JIT	Strings keep their Map hash in their own box, and compiled loops look up Map and Set tables directly (Map get faster than the reference runtime).
JavaScript & JIT	FIX: a fast path for element methods now checks the whole prototype chain, not only the first link.
JavaScript & JIT	Compiled loops take Map and Set keys built as a word plus a number, and Map and Set calls move their arguments instead of copying them.
Rendering	Map with string keys now runs faster than the reference runtime: each site keeps a table of its keys, keys are lent to the store, number values are replaced in place.
JavaScript & JIT	String building now runs faster than the reference runtime: character codes are appended in place; the engine picks the loop compiler or the plan compiler by measuring both.
JavaScript & JIT	The optimizing compiler reads array parameters in place, map and filter build their results in one pass, and a dying array of numbers skips walking its elements.
Rendering	filter writes the kept elements in place, and map and filter buffers skip being filled with zeros first.
JavaScript & JIT	Array methods given an arrow function run it without making a function object, and reduce adds sums as integers (array callbacks now faster than the reference runtime).
JavaScript & JIT	The optimizing compiler reads array elements that are objects (object properties 9.2 -> 4.2 ms); calls that compiled no longer hold back the choice of compiler; compiled code checks for interrupts less often.
JavaScript & JIT	Recursion with a counter runs faster than the reference runtime: a counter bumped at the start of every call is added once after the run.
JavaScript & JIT	FIX: x++ on a variable that holds a string, inside a function the compiler copied into its caller, now converts the string to a number.
JavaScript & JIT	Numeric loops run faster than the reference runtime: multiplying two integers stays an exact integer, range checks are cheaper, and loops build objects whose fields are fixed strings, null or undefined.
Rendering	32-bit arithmetic no longer re-truncates between steps.
Memory & reading	Deaths of up to 4,096 objects at once are freed by the page's own thread instead of being handed to another (cheaper for typical page structures).
Memory & reading	Dying plain objects are freed with less work: their values are read where they lie, with no locking or write-back.
Memory & reading	A new check proves the whole compiler pipeline leaks nothing: memory stays flat over repeated runs of every workload and fast path.
JavaScript & JIT	Values made only by bitwise operations and Math.imul are kept in 32-bit registers in the optimizing compiler (bitwise hash 4.85 -> 4.6 ms).
Rendering	Bitwise hashing now runs faster than the reference runtime: multiply-by-5-plus-a-constant is split so its two halves run side by side (4.6 -> 3.9 ms; the reference runtime 4.6).
Memory & reading	Every small object is 24 bytes smaller (a three-field object 112 -> 88 bytes): object properties 4.2 -> 3.9 ms, and a list of 300,000 small objects takes 6 percent less memory.