feat(runtime): use queued based rendering

[ematipico]

Changes

Added a new experimental engine that is queue based. The engine comes with also a caching system , which can be configured.

The rendering engine also uses batching: all adjacent synchronous nodes that are simple (e.g. strings) are concatenated so that we use one single write.

This is an opt-in engine, and the objective is to consider this a valid evolution of how we render components in Astro.

The explanation of the features is the changeset, but I'm happy to answer any question or doing a deep dive of certain parts of the features.

The feature was created with the help of an AI agent, and I reviewed the majority of the code.

Testing

Many unit tests added to test the new feature.

Docs

withastro/docs#13299

[changeset-bot]

🦋 Changeset detected

Latest commit: a4f39a6

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

Merging this PR will not alter performance

✅ 18 untouched benchmarks

---

_{Comparing refactor/rendere-queue (a4f39a6) with main (be1c87e)}

[ArmandPhilippot]

Following TBD, I don't know if you wanted more data here or on Discord, but running the benchmark locally gives me:

 BENCH  Summary

  Queue Build: hybrid site (static + server) - bench/build-hybrid.bench.js > Bench build time
    1.00x faster than Build: hybrid site (static + server)

  Build: full server site - bench/build-server.bench.js > Bench build time
    1.00x faster than Queue Build: full server site

  Queue Build: rendering static site - bench/build-static.bench.js > Bench build time
    1.17x faster than Build: full static site

  Queue+Pool - bench/render.bench.js > .astro [streaming]
    1.12x faster than Queue
    2.45x faster than Queue+Cache
    2.45x faster than Queue+Pool+Cache
    2.47x faster than Classic

  Queue+Pool - bench/render.bench.js > .astro [buffered]
    1.10x faster than Queue
    2.24x faster than Queue+Pool+Cache
    2.24x faster than Queue+Cache
    2.26x faster than Classic

  Queue - bench/render.bench.js > .md [streaming]
    1.06x faster than Queue+Pool
    1.11x faster than Queue+Cache
    1.16x faster than Classic
    1.18x faster than Queue+Pool+Cache

  Queue+Cache - bench/render.bench.js > .md [buffered]
    1.00x faster than Queue+Pool
    1.01x faster than Queue
    1.03x faster than Classic
    1.12x faster than Queue+Pool+Cache

  Queue - bench/render.bench.js > .mdx [streaming]
    1.51x faster than Queue+Pool
    1.70x faster than Queue+Cache
    2.21x faster than Queue+Pool+Cache
    3.39x faster than Classic

  Queue - bench/render.bench.js > .mdx [buffered]
    1.35x faster than Queue+Pool
    1.56x faster than Queue+Cache
    2.04x faster than Queue+Pool+Cache
    3.05x faster than Classic

I run it twice, above is the most recent one and here's a screenshot I took earlier if that helps!

[sarah11918]

This feature sounds amazing @ematipico ! Some thoughts on the changeset for your consideration! (Will also be looking at the Docs PR today)

[sarah11918]

Just a tiny bit of changeset cleanup here, and please take a look at the config.ts in particular!

[sarah11918]

Suggested change

	With the new engine enabled, you now have the option to have a pool of nodes that can be saved and re-used across page rendering. Node pooling is useless in on-demand rendering (SSR), because rendering requests don't share memory. However, it can be very useful for performance when building static pages.
	With the new engine enabled, you now have the option to have a pool of nodes that can be saved and re-used across page rendering. Node pooling has no effect when rendering pages on demand (SSR), because these rendering requests don't share memory. However, it can be very useful for performance when building static pages.

[sarah11918]

Noting that I'm not reviewing this because there's no @docs tag, but we should manually include the API reference (types, defaults) for poolSize and contentCache on the Experimental docs page!

[yanthomasdev]

A few suggestions from me 🙌

[yanthomasdev]

Looks good to me, just one final suggestion that wasn't applied

[sarah11918]

Approving for docs! 🫡

[yanthomasdev]

LGTM!