perf(compiler): optimize HtmlEscaper escape path - #313
Conversation
Add fast-path optimization for strings that require no HTML escaping, reducing unnecessary allocations for clean input. Agent-Id: agent-30acfca6-f8b9-4bef-a5e5-6e1c93a9ca93 Linked-Note-Id: d7b598f2-2448-4691-89a3-69092fb9f304
Remove intermediate variable assignment by directly returning the clean flag check result. Agent-Id: agent-6007c205-7a4c-42ec-9cfc-3013821dc4c1 Linked-Note-Id: 14632543-8212-46c4-b9c2-f1c2d31b96a3
🤖 Augment PR SummarySummary: Optimizes HTML escaping by removing the per-call 🤖 Was this summary useful? React with 👍 or 👎 |
| if (c <= 96 && (escaped = ESC[c]) != null) { | ||
| // Write from the last replacement to before this one | ||
| if (i > start) writer.write(chars, start, i - start); | ||
| if (i > start) writer.write(value, start, i - start); |
There was a problem hiding this comment.
Writer.write(String, int, int)’s default implementation allocates a new char[] per call; wrappers like LatchedWriter/IndentWriter that only override write(char[], …) may now allocate per clean span and potentially regress perf vs the previous toCharArray+slice approach. Consider validating benchmarks with those writers in the call chain to ensure this stays a win in typical rendering paths.
Other locations where this applies: compiler/src/main/java/com/github/mustachejava/util/HtmlEscaper.java:75
Severity: medium
Other Locations
compiler/src/main/java/com/github/mustachejava/util/HtmlEscaper.java:75
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
a71b412 to
d7a99b8
Compare
Summary
Standalone performance PR for HtmlEscaper (split out from dotted-name work on PR #312).
Changes
Motivation
Profiling of TweetBench / Main.benchEscapeHTML showed escape was a top CPU path and allocated a full copy of every escaped string. Short/clean values (common in template rendering) benefit most; semantics are unchanged.
Test plan