improve compile perf

[benedikt-bartscher]

No description provided.

[greptile-apps]

Greptile Summary

This PR accelerates the deterministic hashing used for compiler auto-memoization by replacing per-node hasher updates with a buffer-based accumulation strategy and a memoized, per-type encoder dispatch table. It also fixes a latent correctness issue where components that inherit from a dataclass (e.g., rx.text via MarkdownComponentMap) were hashed against their (often empty) field list rather than their rendered content.

• Encoder table + bytearray buffer: _update_deterministic_hash (one hasher.update per tree node) is replaced by _encode_deterministic which fills a bytearray, flushed into the MD5 hasher once per top-level value. A per-type _ENCODERS dict is populated lazily so subsequent calls avoid isinstance chains entirely.
• Frozen-dataclass identity cache: _ENCODED_DATACLASSES (an OrderedDict with bounded capacity) caches the encoded bytes of frozen dataclass instances whose fields are all immutable scalars, keyed by object identity. A strong reference in the cache entry prevents id reuse while the entry lives.
• dataclasses.fields() caching: _dataclass_fields_to_encode wraps the per-call tuple rebuild in @functools.cache, eliminating millions of redundant allocations on large apps.

Confidence Score: 5/5

• Safe to merge — the hash encoding is functionally equivalent to the old path for all existing types, the correctness fix for dataclass-inheriting components is well-targeted, and the 18 new tests cover the edge cases thoroughly.
• The buffer-based encoding produces byte-for-byte identical output to the old incremental hasher for every supported type. The encoder table's overwrite ordering is intentional and correct: _encode_frozen_dataclass downgrades its own _ENCODERS entry on the first encounter of a mutable-field type, and the entry is not overwritten a second time because the memoization block only runs when the encoder came from _resolve_encoder, not from the table. The frozen-dataclass identity cache is bounded in both entry count and per-entry size, and strong references prevent stale id lookups. The _get_component_hash refactor preserves the original value ordering and the semantics of the shallow/deep split.
• No files require special attention.

Important Files Changed

Filename	Overview
packages/reflex-base/src/reflex_base/components/component.py	Replaces the incremental _update_deterministic_hash approach with buffer-based _encode_deterministic, adds a type-keyed encoder table (_ENCODERS) with per-type memoization, caches dataclasses.fields() results via @functools.cache, and adds an identity-keyed encoding cache (_ENCODED_DATACLASSES) for frozen dataclass instances with all-scalar fields. Also fixes a pre-existing ordering bug where components inheriting from a dataclass were hashed by their (often empty) field list instead of their rendered content. The encoder table overwrite ordering is intentional and correct — _encode_frozen_dataclass downgrades its own entry on the first encounter of a mutable-field type, and the downgrade persists from the second call onwards. Logic is sound with no correctness regressions.
tests/units/components/test_component.py	Adds 18 focused tests covering: collision resistance, dict-order independence, subclass normalization, Var data inclusion, cache eviction (oldest-first), size cap, frozen-dataclass identity reuse, mutation tracking for non-cacheable types, MutableProxy-style synthesized classes, component-vs-dataclass branch ordering, and _get_component_hash lifecycle-hook sensitivity. The encoding_caches fixture correctly isolates module-level _ENCODERS and _ENCODED_DATACLASSES state for tests that need it. Test test_deterministic_hash_handles_dataclasses_without_params references _HashFrozenScalars defined later in the file, which is valid in Python (function-body lookup is deferred to call time) but may surprise readers.
packages/reflex-base/news/6804.performance.md	Changelog entry accurately describing the 3.7× speedup on large page hashing, the per-type encoder table, identity-keyed frozen-dataclass encoding reuse, and the fix for MarkdownComponentMap-inheriting components.

_{Reviews (11): Last reviewed commit: "Merge remote-tracking branch 'upstream/m..." | Re-trigger Greptile}

[codspeed-hq]

Merging this PR will improve performance by 5.57%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
✅ 24 untouched benchmarks
⏩ 8 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	test_compile_all_artifacts[_stateful_page]	27 ms	25.4 ms	+6.35%
⚡	Simulation	test_compile_page[_stateful_page]	30.6 ms	28.9 ms	+5.8%
⚡	Simulation	test_compile_page_full_context[_stateful_page]	34.6 ms	33.1 ms	+4.58%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing benedikt-bartscher:improve-compile-perf (a642daa) with main (f7c848f)²}

Footnotes

1. 8 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (45b8ed5) during the generation of this report, so f7c848f was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

2 issues found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="tests/units/components/test_component.py">

<violation number="1" location="tests/units/components/test_component.py:2475">
P3: This test's name and docstring claim it verifies that the frozen-dataclass encoding cache is reused by identity, but the two equality assertions would pass even if no cache existed at all (equal-but-distinct instances always encode to the same bytes). Either rename/reword it as a plain equality contract test, or actually exercise the cache path, e.g. clear component._ENCODED_DATACLASSES, hash `shared` once, then assert id(shared) is present in the cache and that a second hash of the same object short-circuits.</violation>
</file>

<file name="packages/reflex-base/src/reflex_base/components/component.py">

<violation number="1" location="packages/reflex-base/src/reflex_base/components/component.py:688">
P2: The new `_ENCODED_DATACLASSES` cache pins up to 8192 frozen dataclass instances and copies of their encoded bytes in a module-global for the whole process lifetime, released only by a full `clear()` once the cap is hit. Because `_deterministic_hash` runs for every component hash during a compile, these scalar-only frozen instances (and their otherwise-transient byte encodings) no longer get garbage-collected, adding persistent memory that was not retained before. The full-clear-on-capacity eviction also drops the entire cache at once and forces re-encoding of the whole working set right at the boundary, so the cache both holds memory and thrashes. Consider evicting/limiting per-entry (e.g. only cache the bytes keyed by object identity while bounding total retained bytes, or evict entries gradually instead of a wholesale clear).</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 3 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[masenf]

seems i haev some overlap here with #6947

[benedikt-bartscher]

seems i haev some overlap here with #6947

yeah, maybe we can try to get best of both worlds?