perf: reuse the params and top scope tables across renders (0160)

[rmorozov]

Requested by Ruslan · project thread

Before: every render built a fresh robin_hood map for its params (2 allocations, 558 B), and a template with many top-level sets grew its top scope table from scratch each time. Render/many_tags spent 15 allocations, 82 KB and 6 rehashes (15% of its instructions) per render.

After: the thread's RenderWorkspace lends each render a params map and a top scope map and takes them back emptied. clear() keeps the bucket array and returns the nodes to the table's pool, so a steady render allocates nothing for either. many_tags drops to 2 allocations and 5.6 KB per render.

How: RenderWorkspace::LendMaps/ReturnMaps in stack order, so a render started inside another (a user callable rendering a template) is lent the next pair. Tables past 1024 buckets, and tables of renders nested deeper than four levels, are let go rather than kept on the thread. RenderContext gets a constructor that takes the top scope map (moved in only when it has a table) and TakeTopScope, called after a clean render; a failed render just drops the table.

Measured (local callgrind, Release, against 1ca9c15): many_tags -4.6..-5.1% instructions (15 -> 2 allocs, peak 82,520 -> 5,632 B), substitute -13.2%, large_static -1.8%, others -0.7..0%, plain_text +1.5% (+15 instructions: the thread-local workspace lookup and lend). Every case with params: -2 allocations, -558 B. Details in docs/tasks/0160.

Roles: verifier (1 round, Sonnet). It found one blocking issue, clang-tidy misc-include-cleaner on changed lines, which was already fixed in the second commit; sanitizers (clang ASan+UBSan), nested/throwing renders, threads and wide templates were clean. Its non-blocking note on deep nested renders holding tables is addressed in the third commit. Red pushes in CI: none yet.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QFPahQrfHfhtFndTYZmPTe

---

Generated by Claude Code