Repository navigation
perf(query): cache literal keyword entity resolutions (#774) - #788
Merged
Merged
Conversation
adityamukho
force-pushed
the
perf/774-expression-keywords
branch
from
October 29, 2026 04:11
17b6a56 to
04d0294
Compare
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Queries such as
[:find ?f :where [?f :name ?n] [(= ?f :p5)]]resolved the same literal keyword once per input row. Resolve literals when each filter/binding operator is built and reuse them across rows and rewinds. The immutable cache is bounded by expression literals, including nested expressions and substituted prepared slots; dynamic operands never enlarge it. Equality semantics, public APIs, dependencies and storage formats are unchanged.Measurement preceded implementation. On idle, pinned benchmark runs at 100K and 1M facts, four socket-swapped pairs per shape show 9.0–11.0% lower latency for named-keyword
=/!=in both operand orders. The report retains UUID-keyword controls, scan/join guards, and a 20-pair point-query repeat. The final comparison uses current v3 at5f8073250; the report separately retains the measurements gathered before implementation. This is not a general-query speedup claim. Expression metadata, like parsed query text, remains outside the query data-memory meter.Validation: the regression counter failed before the change (8 → 2,048 conversions as rows increased) and passes afterward across plain/nested/binding/negation/disjunction/rule expressions. Full default suite: 1,989 passed, 17 ignored. Targeted
test-hooksequality/plan-independence suites: 31 passed. Strict all-feature clippy and formatting pass. Prepared keyword slots are alternated across executions, including checkpoint/reopen tests.Raw measurements, lockfile, reproduction driver and limitations are in
docs/benchmarks/774-expression-keywords.md. Repository status/test documentation is synchronized. Companion docs-site PR #85 documents the v3-only behavior; its build passed across 13 versions and 368 pages.Fixes #774. Targets
v3; no v2.x performance backport.Rebased onto #723. A compact literal table keeps the release binary at 1,263,016 bytes, within the unchanged 1,263,616-byte cap. The full default suite and targeted test-hooks suites, lint and formatting were rerun after rebasing.