memfs-kit v1.1.1

This patch release reduces small-read and directory-entry metadata overhead
while preserving the existing API, snapshots, hooks and concurrency guarantees.

Highlights

• File.Read explicitly unlocks its two return paths, reducing the deferred
  unlock wrapper work on small reads. The same mutex still protects the closed
  check, content access and cursor update.
• Directory entries without a regular-file hook own an immutable metadata
  snapshot that Info returns directly, avoiding another allocation per call.
  This also applies to directory entries when a hook is configured. Returned
  metadata stays usable after the entry slice or directory handle is discarded.
• Regular-file entries with hooks keep their lazy per-entry result, including
  concurrent initialization, cached errors and replay of a hook panic. Listing
  names still does not run hooks, and callbacks execute outside internal locks.
• The English and Chinese documentation now distinguishes captured stored
  metadata from lazy hook metadata, identifies each performance baseline, and
  records release verification steps.

Measured results

The local comparison used Go 1.27.3, darwin/arm64, Apple M5,
GOMAXPROCS=1, with six adjacent AB/BA pairs per scenario in one binary
(-benchtime=200ms -count=1 -cpu=1). It compared the runtime implementation in
this release with published v1.1.0
(d69c7500e0034579d72819a2a05cda1f97de960e). Percentages use the median of
paired ratios, not the ratio of separately computed medians.

• Opening a fresh 4 KiB file, reading through EOF in 64 B chunks and closing it
  took 16.7% less time. The 16 B and 256 B chunk cases improved similarly;
  allocation remained 128 B and one allocation per operation.
• Listing 1,000 entries and calling every Info took 26.9% less time.
  Allocation fell from 144,512 to 80,512 B/op (44.3% less) and from
  2,002 to 1,002 allocations/op.
• Names-only listings retained their previous allocation counts. Repeated
  no-hook Info calls became allocation-free; fresh hook listings plus every
  Info were approximately unchanged in time and allocations.

These measurements describe specific microbenchmarks, not application
throughput. In a separate paired comparison with original soulteary/memfs
v0.1.0, the 1,000-entry listing plus every Info took about 18.9% less time,
while the 64 B chunk read still took about 48% more time. This release keeps
the per-handle synchronization absent from the original implementation. The
original comparison uses a static tree and independent handles.

See the performance notes
for workloads, reproduction commands, allocation data and limitations.

Installation

Requires Go 1.27.3 or newer, unchanged from v1.1.0.

go get github.com/soulteary/memfs-kit@v1.1.1

import memfs "github.com/soulteary/memfs-kit"

There are no third-party Go module dependencies. The module path and package
name are unchanged.

Compatibility and validation

No exported methods or signatures change. Snapshots, error behavior, content
ownership, hook paths and timing, per-listing caches and synchronization are
preserved. Seek, ReadAt and Close retain their existing behavior. Wrappers
that override Open still need to handle promoted Stat and ReadDir methods;
see optional-interface dispatch.

Validation includes Linux, macOS and Windows tests, the full race-enabled suite
with 97.9% statement coverage, 15-second/two-worker path fuzzing, formatting,
vet, module checks and a smoke run of every benchmark. New regression tests
cover read/cursor boundaries, shared-handle byte consumption, retained file and
directory metadata, and hook panic caching. They also pass against v1.1.0 to
check that the existing contracts are preserved.

Licensing

The project uses Apache License 2.0. Code inherited from memfs retains its
BSD-3-Clause license and original notices. See
LICENSE,
the preserved BSD license,
and third-party notices.