Performance: Arc<Value> pop/push cycle overhead for heap types #368
Labels
No labels
bug
dependencies
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
refactor
rust
technical-debt
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
navicore/patch-seq#368
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
Every
pop()of a heap value doesArc::try_unwrap(decrement + potential free), and everypush()doesArc::new(allocate + increment). For operations that pop a value, transform it, and push it back, this creates an unnecessary alloc/dealloc cycle even when the value is sole-owned.This affects all heap types (Float, String, Variant, Map, Channel, etc.) on every operation.
Impact
The build-100k benchmark calls
list.push100,000 times. Each call does:popvalue (Int — inline, cheap)poplist (Arc::try_unwrapon outerArc<Value>)Arc<VariantData>(works correctly)pushresult (Arc::newto wrap in newArc<Value>)Steps 2 and 4 allocate and free an Arc per operation, even though the value is sole-owned throughout.
Potential Approaches
u64tagged pointer without going throughValue. Read theArc<Value>pointer, reach into the inner data, mutate, write back. No Arc alloc/dealloc.Arc<Value>with arena-allocated heap objects that use inline refcounting. Clone is a refcount bump, drop is a decrement — no allocation at all.Arc<Value>for cross-strand sharing but use a lighter wrapper for strand-local operations.Context
This was identified during the tagged-ptr migration (PR #367). The COW optimization for collections (Vec fields + Arc::get_mut) is correct but its benefit is limited because the surrounding pop/push infrastructure dominates the cost.
A targeted workaround (
list.push!) is being added for the most critical path, but the underlying issue affects all heap type operations.@navicore-bot please consider working this issue if you find a feasible approach that doesn't compromise the tagged-ptr work recently completed.
Completed. The Arc pop/push overhead is eliminated for all hot-path operations via
peek_heap_mut/heap_value_mutprimitives:Sole-owned heap values are now mutated in place without the Arc alloc/dealloc cycle. Shared values fall back to the existing clone path.