Skip to content

Add a compact bulk layout read path #41

Description

@hyfdev

Problem

Reading layout for many nodes currently performs one binding call per node. Each call creates a rich Layout containing 21 numeric values across several nested objects.

This cost dominates simple layouts and is particularly expensive through the napi-rs WASI runtime.

Evidence

Reading 500 layouts individually took approximately:

  • Native: 0.95 ms.
  • WASI: 9.8 ms.

A diagnostic operation that transferred the four observed geometry values for all 500 nodes in one packed buffer took approximately:

  • Native: 0.068 ms.
  • WASI: 0.52 ms.

These diagnostic values exclude reconstruction of the normal public Layout objects, but they demonstrate the cost of repeated crossings and nested native object creation.

Direction

Add a compact raw transport that reads multiple layouts in one binding call.

Expose an additive public batch operation, with the final API name reviewed separately, that returns normal detached Layout snapshots in the same order as the supplied node IDs. Preserve the existing single-node methods.

Rounded and unrounded layout semantics must remain explicit and consistent with getLayout() and getUnroundedLayout().

Acceptance criteria

  • A batch requires one native or WASI binding call rather than one call per node.
  • Returned layouts preserve input order and the existing public Layout shape.
  • Rounded and unrounded variants have defined behavior.
  • Invalid, removed, foreign, and forged node IDs retain precise error behavior.
  • Existing single-node APIs remain compatible.
  • Native and WASI behavior tests verify equality with repeated single-node reads.
  • End-to-end benchmarks use the public batch API in a documented transaction.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions