Skip to content

Speed up rendering and close a few compile-time holes - #32

Closed
gregjotau wants to merge 2 commits into
mainfrom
faster-html-output
Closed

Speed up rendering and close a few compile-time holes#32
gregjotau wants to merge 2 commits into
mainfrom
faster-html-output

Conversation

@gregjotau

Copy link
Copy Markdown
Contributor

Why

Render speed is now measured. The first pass over HtmlOutput was still
per-character with a flush check on every byte, integers walked a divisor,
and application-relative TrustedUrls allocated even when the context path
was empty. Spring also flushed a 1KiB buffer. A few dead-code and
reference checks were inconsistent with the rest of the compiler.

What

  • Single-pass HtmlOutput.text and reverse-digit text(long)
  • RenderContext.resolveUrl returns the same string when the context path is empty
  • Golden HTML plus a reference encoder, including tiny-buffer equality
  • failOnUnusedFragments also fails unused fragment parameters
  • #id targets on href / hx-target / hx-include / hx-indicator must exist
  • Spring HtmlOutput buffer matches the 16KiB runtime default

Local JMH: inbox ~1.55µs → ~1.02µs, catalog/50 ~5.4µs → ~3.7µs, integers ~1.0µs → ~0.43µs.

How to check

./gradlew test
./gradlew :benchmark:jmh

Write ASCII and UTF-8 in a single pass through the output buffer, encode
integers without the old divisor walk, and skip context-path concatenation
when the path is empty. Golden pages and a reference encoder keep the
bytes identical, including across tiny buffers.
failOnUnusedFragments now also fails unused fragment parameters. Hash
targets on href, hx-target, hx-include, and hx-indicator must resolve
to an id on the page. Spring renders through the same 16KiB HtmlOutput
buffer as the rest of the runtime.
@gregjotau

Copy link
Copy Markdown
Contributor Author

Closing as a stale, conflicted bundle rather than merging it wholesale. The safe unused-fragment-parameter part shipped in #46. The proposed static hx-target/hx-include/hx-indicator ID validation was tested against all consumers and produced false positives for conditional targets, so it needs reachability-aware DOM modeling before it can be sound. The rendering performance changes should return as a focused PR with benchmark evidence.

@gregjotau gregjotau closed this Aug 22, 2026
@gregjotau
gregjotau deleted the faster-html-output branch August 22, 2026 07:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant