Skip to content

Add ContiguousMap.CopyKeysTo/CopyValuesTo and obsolete the copying *Span accessors [minor] - #145

Open
matt-edmondson wants to merge 1 commit into
mainfrom
fix/102-copy-keys-values
Open

matt-edmondson wants to merge 1 commit into
mainfrom
fix/102-copy-keys-values

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

Fixes #102

What was wrong

ContiguousMap.GetKeysSpan() and GetValuesSpan() return a ReadOnlySpan<T>, and their remarks promised "direct access … from the contiguous memory". In fact every call allocated a new array and copied every entry, so for (i …) map.GetKeysSpan()[i] was O(n²) and allocated n arrays. Entries are stored as Entry { Key, Value } structs, so a keys-only view can't exist without a copy.

Change

This follows the option recommended in the issue's triage comment:

  • New: CopyKeysTo(Span<TKey>) and CopyValuesTo(Span<TValue>) fill the start of a caller-owned buffer in insertion order, with no allocation. A destination shorter than Count throws ArgumentException (ParamName == "destination") before anything is written.
  • Obsoleted, not removed: GetKeysSpan and GetValuesSpan are now [Obsolete] as a warning, not an error, so existing callers keep compiling. The message points at the new Copy*To method and at AsReadOnlySpan() for zero-copy access to Entry.Key/Entry.Value. They now delegate to Copy*To, and their remarks state that each call allocates. Removing them would be a [major] change and is left for later.
  • Benchmark: ContiguousMap_SpanAccess was timing the copy as if it were span access. It now iterates AsReadOnlySpan().

The existing GetKeysSpan/GetValuesSpan tests still run, wrapped in a local #pragma warning disable CS0618.

Tests

  • New in ContiguousMapTests: insertion-order copies for keys and values, a longer destination keeps its tail, and a shorter destination throws without writing (keys and values).
  • CopyKeysAndValuesTo_DoNotAllocate: GC.GetAllocatedBytesForCurrentThread() shows 0 bytes for both copies.
  • CopyingSpanAccessors_AreObsoleteAndPointAtTheirReplacement: reflection checks the [Obsolete] attribute, its message, and that IsError is false.
  • Checked against the old code: with only the two [Obsolete] attributes removed, both cases of the obsolete test fail. On main, the new tests don't compile (CS0117, no CopyKeysTo/CopyValuesTo).
  • Full Containers.Test suite: 524 passed, 0 failed. The solution builds with no warnings, and dotnet pack (package validation) succeeds.

Generated by Claude Code

…pan accessors [minor]

GetKeysSpan and GetValuesSpan read as zero-copy views, but every call
allocated a new array and copied the whole map, so an indexed loop over
them was O(n²). CopyKeysTo(Span<TKey>) and CopyValuesTo(Span<TValue>)
fill a caller-owned buffer without allocating. The *Span methods keep
working, now through those, but are marked [Obsolete] (a warning, not an
error) pointing at the replacements and at AsReadOnlySpan() for
zero-copy access to Entry.Key/Value.

The ContiguousMap span-access benchmark now measures AsReadOnlySpan,
the real zero-copy path, instead of the copy.

Fixes #102

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vfJW6AfToAg6F8bcZwwZ5
@sonarqubecloud

sonarqubecloud Bot commented Nov 4, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ContiguousMap.GetKeysSpan/GetValuesSpan allocate and copy the whole map on every call, making indexed loops O(n²)

2 participants