Skip to content

Release v0.13.4

Latest

Choose a tag to compare

@github-actions github-actions released this 20 Jun 20:36
· 2 commits to main since this release

Highlights

  • Actors are about twice as fast. Each one now runs on its own thread and evaluates its closure inline, instead of bouncing every frame to a worker thread and back. A trivial actor goes from 40K to 90K frames/s; large replays, like rebuilding a projection with start: "first", gain the same.

  • A per-frame memory leak is fixed. Every closure call used to add a job to a table that was never pruned, so a long-lived actor grew without bound. The loop now reuses one job.

  • Reads can filter on several topics at once. Pass a comma list or a Nushell list to xs cat --topic, .cat / .last, the HTTP topic param, or a new actor topics field:

    .cat -T "game.move.*,game.create"
    .cat -T [game.move.* game.create]
    

    Each pattern scans its own index; the results merge by frame id, in time order, deduped (a MergeAppend, in Postgres terms). An actor with a topics filter skips unwanted frames before the closure runs: 2.4us each instead of 9.3us when one in ten matches.

  • Embedders can supply a base Nushell engine that processors clone, so their own commands reach actors, services, and actions (Store::with_base_engine, #144).

  • A new benchmark covers the store and actor paths: cargo bench --bench throughput.

This release is non-breaking; upgrading from 0.13.3 needs no store or script changes.

Changelog

  • feat: .cat/.last accept a Nushell list of topic patterns
  • feat: let a Store carry a base engine that processor engines clone (#144)
  • test: last:n ttl can hide a module version from an earlier create
  • docs: add TTL reference and module-pruning caution
  • feat: accept multiple comma-separated topic patterns on reads
  • bench: add replay-topic and actor-mixed dimensions
  • docs: add Read Options reference, consolidate read docs onto it
  • bench: add store and actor throughput benchmarks
  • refactor: run the actor loop on a dedicated thread with inline eval