Native record representation + inline nil?/some? (#222)
Records were a jrec holding an alist of (kw . val) conses: ~113B/node, built fresh per construction, field reads a list scan. Replace that with a shared per-type descriptor (tag + field keywords + an eq?-keyed keyword->index table) plus a flat per-instance value vector and an extension map for any non-field keys assoc'd on (jolt-nil when there are none). Construction now allocates one vector instead of a cons chain and a field read is an index lookup. binary-trees construction allocation drops 2.085GB -> 1.19GB. That alone barely moved binary-trees wall-time: profiling showed the read loop, not allocation, dominates, and the read loop's own allocation came from (nil? l) lowering to (jolt-invoke (var-deref "clojure.core" "nil?") l), which conses its args every call. Add nil?/some? to the backend native-op table so they inline to jolt-nil?/jolt-some? (and drop the truthy wrapper, like the other predicates). check-tree's read loop goes from 1.476GB allocated to zero; binary-trees 18.9x -> 9.7x vs JVM. The remaining gap is the field-read dispatch chain (jolt-c3mw). Two JVM divergences fixed along the way, both certified: - dissoc of a declared field downgrades a record to a plain map (was kept as a record); an extension key still drops cleanly. - map->R keeps extension keys (was dropping anything outside the declared basis). 16 new corpus rows pin assoc/dissoc/count/keys/seq/=/hash/extension-field behavior against JVM Clojure. Co-authored-by: Yogthos <yogthos@gmail.com>
This commit is contained in:
parent
eacfa04e5b
commit
8bea1abe12
8 changed files with 1049 additions and 934 deletions
File diff suppressed because one or more lines are too long
Loading…
Add table
Add a link
Reference in a new issue