Process various AI perf suggestions

[idg10]

A colleague asked several AIs what we might do to improve performance. I've dumped the results here. We should work through these to see which suggestions look worthwhile, and create separate work items if appropriate:

Gemini 3 Pro

Performance Improvements for Ais.Net

This document outlines suggested performance improvements for the Ais.Net library, targeting .NET 10 and C# 14. The goal is to achieve zero-allocation, high-performance code suitable for modern CPU architectures.

1. Modern .NET & C# Features

1.1. UTF-8 String Literals

Current: Encoding.ASCII.GetBytes("VDM") creates a byte array at runtime (or static init).
Recommendation: Use C# 11 UTF-8 string literals ("VDM"u8). This compiles directly to a ReadOnlySpan<byte> pointing to the data section of the assembly, avoiding array allocation and initialization overhead.

1.2. SequenceReader<T> for Parsing

Current: NmeaLineParser and NmeaTagBlockParser manually slice spans and search for delimiters.
Recommendation: Use System.Buffers.SequenceReader<byte>. It provides optimized methods for reading primitives, advancing, and searching, often using SIMD under the hood. It also handles ReadOnlySequence<byte> natively, which is crucial for fragmented data (see 2.1).

1.3. SkipLocalsInit

Current: Default zero-initialization of locals.
Recommendation: Apply [SkipLocalsInit] to performance-critical methods (like NmeaAisBitVectorParser.GetUnsignedInteger) to avoid the cost of zeroing stack memory, especially when using stackalloc.

1.4. SIMD Vectorization

Current: Scalar processing of bits and bytes.
Recommendation:

• Comma Finding: Use Vector128<byte> or Vector256<byte> (via Vector128.Create((byte)',')) to find delimiters in NmeaLineParser in a single pass, rather than repeated IndexOf calls.
• 6-bit Decoding: Investigate using SIMD to decode multiple 6-bit ASCII characters in parallel. While bit-packing is tricky, AVX2/AVX-512 instructions (like vpmultishiftqb or shuffle) can sometimes perform parallel bit extraction and packing.

2. Memory Management & Allocations

2.1. Zero-Copy Reassembly of Fragmented Messages

Current: NmeaLineToAisStreamAdapter allocates a new buffer for each fragment, copies data into it, then allocates a larger buffer to combine them, and copies again.
Recommendation:

• Store fragments as a list of ReadOnlyMemory<byte> (or ReadOnlySequence<byte> segments).
• Construct a ReadOnlySequence<byte> representing the logical contiguous payload.
• Update NmeaAisBitVectorParser and NmeaPayloadParser to accept ReadOnlySequence<byte> (or use SequenceReader).
• This eliminates the large allocation and copy for reassembly.

2.2. Eliminate Dictionary in Hot Path

Current: NmeaLineToAisStreamAdapter uses Dictionary<int, FragmentedMessage> to track fragments.
Recommendation:

• If group IDs are small/dense, use an array.
• If sparse, consider a FrozenDictionary (if static) or a specialized high-performance map (like SwissTable implementation or open addressing) to reduce overhead.
• Since this is a read-write cache, a pooled object approach for the FragmentedMessage containers would reduce GC pressure.

2.3. Fix Repeated Parsing in NmeaLineParser.TagBlock

Current: Accessing parsedLine.TagBlock creates a new NmeaTagBlockParser which immediately parses the entire tag block. NmeaLineToAisStreamAdapter accesses this property multiple times per line, causing redundant parsing.
Recommendation:

• Change the pattern so the caller parses once and stores the result.
• Or, make NmeaTagBlockParser lazy and lightweight (only parse when specific fields are requested), though this is harder with ref struct.
• Best approach: Parse tag block once into a struct of results if needed, or pass the NmeaTagBlockParser instance around.

2.4. Lookup Table for 6-bit Decoding

Current: NmeaPayloadParser.AisAsciiTo6Bits uses nested ternary operators and branches.
Recommendation: Use a static ReadOnlySpan<byte> lookup table (size 128). This makes decoding branchless and extremely fast (O(1) memory access).

3. API & Architecture

3.1. Exception Handling

Current: NmeaLineParser and NmeaPayloadParser throw exceptions (ArgumentException, NotSupportedException) for invalid data.
Recommendation:

• In high-throughput streams, invalid data (noise) is common. Exceptions are extremely expensive (stack trace generation).
• Use a TryCreate or TryParse pattern returning a bool or a status enum (OperationStatus).
• Only throw for truly exceptional, unrecoverable errors (e.g., internal state corruption), not for bad input data.

3.2. System.IO.Pipelines Optimization

Current: NmeaStreamParser manually creates a Pipe and a background task to copy Stream to Pipe.
Recommendation:

• Use PipeReader.Create(Stream) which is optimized and handles buffering/copying efficiently.
• Avoid the manual ProcessFileAsync loop.
• Tune buffer sizes dynamically or based on empirical data rather than hardcoded 1MB/1KB.

3.3. NmeaLineToAisStreamAdapter Redundant Parsing

Current: When reassembling, NmeaLineToAisStreamAdapter creates a new NmeaLineParser for each fragment to extract the payload.
Recommendation:

• The payload offset and length should be calculated once when the fragment is first received and stored in FragmentedMessage.
• When reassembling, use these stored offsets to slice the buffer directly without re-parsing the NMEA structure.

4. Micro-Optimizations

• GetSingleDigitField: Replace manual char math with u8 subtraction or Utf8Parser.
• Math.Min: In NmeaAisBitVectorParser, Math.Min might add a branch. Bitwise operations can sometimes replace it.
• stackalloc: Ensure stackalloc is used for small temporary buffers (like the fragment removal list) to avoid GC pressure.
• MethodImplOptions.AggressiveInlining: Apply to small hot methods like AisAsciiTo6Bits (if not using lookup table) or bit extraction helpers.

5. Benchmarking Strategy

Before applying these changes:

1. Run existing benchmarks in Solutions/Ais.Net.Benchmarks.
2. Create new benchmarks specifically for:
   • NmeaLineParser constructor (parsing speed).
   • NmeaAisBitVectorParser.GetUnsignedInteger (decoding speed).
   • NmeaLineToAisStreamAdapter (fragment reassembly overhead).
3. Profile using dotnet-trace or dotMemory to confirm allocation hotspots.

gpt5.1

Ais.Net Solutions Performance Review (2025)

This document records performance-focused observations and recommendations from a review of the Solutions tree as of 2025-12-09, with a particular focus on the hot parsing path in Ais.Net.
The existing codebase already uses modern low-allocation techniques (e.g., ref struct, Span<T>, ArrayPool<T>, System.IO.Pipelines); most suggestions below are incremental, targeted optimizations or opportunities to take advantage of .NET 8–10 and C# 12+.

---

1. Target frameworks and runtime feature usage

1.1 Drop legacy netstandard2.0-only paths and unify on modern runtimes

Files:

• Ais.Net/Ais/Net/NmeaStreamParser.cs (#if NETSTANDARD2_0 block in CreateFileReader)

Observation

• CreateFileReader still carries a #if NETSTANDARD2_0 branch that uses MemoryMarshal.TryGetArray and Stream.ReadAsync(byte[], int, int); the non-NETSTANDARD2_0 path already uses Stream.ReadAsync(Memory<byte>).
• This conditional complexity is only necessary if you still ship a netstandard2.0 build; it prevents usage of newer BCL and JIT features that assume a modern baseline.

Recommendation

• If your deployment matrix now allows, drop netstandard2.0 (and ideally netstandard2.1) and target only modern TFMs (e.g., net8.0, net9.0, net10.0) for Ais.Net.
• Remove the #if NETSTANDARD2_0 branch in CreateFileReader and always use ReadAsync(Memory<byte>) with the newer FileStream implementation; this unlocks additional JIT and I/O optimizations available only in current runtimes and simplifies the code.

Impact

• Slight reduction in per-read overhead and improved I/O throughput on modern runtimes; simplifies maintenance and enables further adoption of new APIs (e.g., FileStreamOptions, RandomAccess, Stream.ReadExactlyAsync).

---

2. NMEA stream ingestion (NmeaStreamParser)

File:

• Ais.Net/Ais/Net/NmeaStreamParser.cs

2.1 File open and I/O strategy

Observation

• ParseFileAsync(string, INmeaLineStreamProcessor, NmeaParserOptions) opens the file with:

  using var file = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite, bufferSize: 1, useAsync: true);

  and then builds a custom Pipe-based reader in CreateFileReader.
• Buffer size 1 disables FileStream's internal buffering, forcing every call to the custom reader to result in a kernel I/O call, shifting all buffering into the custom Pipe.

Recommendations

• Re-evaluate whether you still need a custom Pipe implementation in CreateFileReader now that .NET ships an optimized PipeReader.Create(Stream, StreamPipeReaderOptions) implementation:
  • Replace CreateFileReader with PipeReader reader = PipeReader.Create(stream, new StreamPipeReaderOptions(bufferSize: N, minimumReadSize: M)); and remove the Pipe + ProcessFileAsync scaffolding.
  • Tune bufferSize/minimumReadSize (e.g., 64–256 KiB) based on real-world log sizes; this removes the 1 MiB segment size guess and automatically tracks runtime tuning.
• If you keep the custom Pipe, consider:
  • Using a realistic FileStream buffer size (e.g., 64 KiB) instead of 1, and profiling whether the combination of FileStream buffering + Pipe is faster than forcing all buffering into the Pipe alone.
  • Calling writer.GetMemory(desiredSize) with a non-trivial desiredSize (e.g., 64 KiB) to reduce the number of small writes into the Pipe.

Impact

• Potentially significant throughput improvement on high-latency or high-bandwidth storage by reducing syscalls and better utilizing the runtime's I/O heuristics.

2.2 Line splitting loop

Observation

• ParseStreamAsync processes the PipeReader buffer by scanning for \n using ReadOnlySequence<byte>.PositionOf((byte)'\n') and manually reassembling multi-segment lines into a fixed splitLineBuffer of size 1000.
• For IsSingleSegment, lineSpan = line.First.Span; is zero-allocation; for multi-segment lines, a copy into splitLineBuffer is performed per line.

Recommendations

• Confirm that the 1000-byte splitLineBuffer upper bound is safe for all expected NMEA line sources; if longer lines are possible, consider:
  • Switching to an ArrayPool<byte>-backed buffer sized to the longest observed line; or
  • Using a per-fragment ArrayPool<byte>.Shared.Rent()/Return() pattern for rare long lines, keeping the stack-allocated or fixed 1 KiB path for the majority.
• Evaluate re-implementing the scan using System.Buffers.SequenceReader<byte> (available in modern runtimes) which offers optimized line-oriented reading utilities and can reduce manual PositionOf/slice juggling.

Impact

• Eliminates potential truncation risk on pathological long lines and can slightly reduce CPU overhead on multi-segment lines by leaning on tuned framework primitives.

2.3 Progress accounting

Observation

• Progress uses Environment.TickCount and reports every LineCountInterval = 100000 lines; the counters and time calculations are 32-bit integer-based.

Recommendations

• If extremely long-running processes are expected, consider migrating to Stopwatch.GetTimestamp() for higher-resolution wall-clock measurement and immunity to TickCount wraparound.
• Keep the reporting cadence high enough for operational observability but low enough not to materially affect throughput (100k lines is sensible; adjust based on observed workloads).

Impact

• Mostly robustness and diagnosability; negligible effect on throughput, but important for long-lived processes.

---

3. Sentence parsing (NmeaLineParser)

File:

• Ais.Net/Ais/Net/NmeaLineParser.cs

3.1 Character classification

Observation

• The parser validates that the payload padding field is numeric via:

  if (nextComma < 0 || remainingFields.Length <= (nextComma + 1) || !char.IsDigit((char)remainingFields[nextComma + 1]))

• char.IsDigit(char) is globalization-aware and more expensive than necessary when the input is guaranteed ASCII.

Recommendation

• On modern frameworks, switch to char.IsAsciiDigit((char)remainingFields[nextComma + 1]), which is explicitly optimized for ASCII input and avoids globalization costs.

Impact

• Small but measurable CPU reduction in the hot parse loop when processing very large numbers of messages.

3.2 Tag block parsing reuse

Observation

• TagBlock is implemented as:

  public NmeaTagBlockParser TagBlock => new NmeaTagBlockParser(this.TagBlockAsciiWithoutDelimiters, this.throwWhenTagBlockContainsUnknownFields);

• Each access reconstructs and re-parses the tag block span; in NmeaLineToAisStreamAdapter.OnNext the property is accessed multiple times per line when tag blocks are present.

Recommendation

• If profiling shows tag block-heavy traffic, consider caching a parsed NmeaTagBlockParser inside NmeaLineParser, constructed lazily on first access:
  • Use a private bool tagBlockParsed; + NmeaTagBlockParser tagBlock; inside the ref struct and only parse once when TagBlock is accessed.
  • Because NmeaTagBlockParser is a ref struct, it can be stored as a field in another ref struct without heap allocation.

Impact

• Reduces CPU cost for scenarios with frequent tag blocks and multiple consumers of TagBlock on the same parsed line.

3.3 Minor branch and slicing optimizations

Observations & Suggestions

• this.Sentence.Slice(3, 3).SequenceEqual(VdmAscii) and the corresponding VDO check perform two Slice operations per line; for very high message rates you could:
  • Manually compare Sentence[3], Sentence[4], Sentence[5] to 'V', 'D', 'M'/'O' to avoid the extra span creation and SequenceEqual call.
• GetSingleDigitField assumes fields are a single digit or empty; if the protocol may evolve to multi-digit counts, consider adding a non-throwing TryGetIntField that handles multi-digit ASCII integers via Utf8Parser, mirroring the approach in NmeaTagBlockParser.

Impact

• Micro-optimizations that likely only matter on the very hottest paths under extreme throughput; should be guarded by benchmark evidence before changing for readability reasons.

---

4. Fragment reassembly (NmeaLineToAisStreamAdapter)

File:

• Ais.Net/Ais/Net/NmeaLineToAisStreamAdapter.cs

4.1 Redundant re-parsing of fragments

Observation

• When handling fragmented messages, fragments are stored as rented byte[] buffers.
• To determine whether all fragments have arrived and to compute totalPayloadSize, each fragment buffer is wrapped in a fresh NmeaLineParser multiple times:
  • Once in the loop that checks for missing fragments and sums payload lengths; and
  • Again in the reassembly loop when copying payloads and retrieving final padding.

Recommendation

• Cache minimal per-fragment metadata alongside the byte[] in FragmentedMessage to avoid repeated parsing:
  • On first receipt of a fragment, parse once with NmeaLineParser and store PayloadOffset, PayloadLength, and Padding (or the ReadOnlySpan<byte> slice indices) in a small value type.
  • Use these cached offsets/lengths for the allFragmentsReceived check and the reassembly copy instead of re-parsing.

Impact

• Reduces CPU per fragmented message, especially when handling high rates of type 5/24 messages that are commonly split across multiple sentences.

4.2 Group expiry and stack allocation size

Observation

• OnNext builds a Span<int> fragmentGroupIdsToRemove = stackalloc int[this.messageFragments.Count]; when there are outstanding fragments.
• Under heavy fragmentation load, messageFragments.Count could become large; a large stackalloc (thousands of ints) increases stack pressure and risks stack overflow in extreme cases.

Recommendation

• Replace the stackalloc with an ArrayPool<int>.Shared-backed buffer, or use a small, fixed-size stackalloc (e.g., 64/128) and fall back to a pooled array when more capacity is needed.
• Alternatively, track expiration lazily: store the lineNumber when each FragmentedMessage was last updated and periodically scan only a bounded number of entries per call to amortize work.

Impact

• Improves robustness and stack safety under worst-case fragmentation patterns without materially increasing allocations.

4.3 Logging and cleanup allocations

Observation

• FreeRentedBuffers uses this.messageFragments.Keys.ToArray() and writes directly to Console for each group with missing fragments.
• This path is typically only exercised at shutdown or error, but in high-volume scenarios with many partial fragments it can allocate and write a large amount.

Recommendations

• If partial fragments are expected to be common (e.g., noisy radio environments), consider:
  • Replacing Keys.ToArray() with an ArrayPool<int>.Shared-backed buffer and manual enumeration; or
  • Emitting only summary statistics (count, max age, etc.) to avoid per-group logging.
• If runtime logging infrastructure exists, route these messages through that logging abstraction to enable sampling or level-based suppression instead of unconditional Console.WriteLine.

Impact

• Reduces heap allocations and I/O overhead in failure-heavy environments while preserving debuggability.

4.4 Error handling strategy for noisy inputs

Observation

• Many invalid states result in ArgumentException (e.g., duplicate sentence in group, non-zero padding in non-final fragments), which surface via OnError.
• If the typical environment sees frequent syntactically invalid messages, exception throwing and stack trace capture can become a dominant CPU cost.

Recommendation

• Introduce non-throwing Try* parse paths for expected error patterns (e.g., TryHandleFragment returning a status enum) and use error codes instead of exceptions for recoverable invalid inputs.
• Keep exception-based paths for genuinely exceptional states (internal invariants violated) and for public APIs where misuse must be clearly signaled.

Impact

• Potentially large CPU savings when processing noisy streams, at the cost of some additional branching and complexity in the adapter.

---

5. Bit-vector decoding (NmeaAisBitVectorParser and friends)

File:

• Ais.Net/Ais/Net/NmeaAisBitVectorParser.cs

5.1 Bit extraction loop

Observation

• GetUnsignedInteger iteratively shifts result left and ANDs/masks out bits from each 6-bit AIS character, handling arbitrary bit offsets and lengths up to 32 bits.
• This is a central primitive for all message-type-specific parsers, and is likely on the hottest path for normal operation.

Recommendations

• Benchmark GetUnsignedInteger under realistic workloads using BenchmarkDotNet targeting modern runtimes; if it dominates CPU time:
  • Explore unrolling the loop for common bit widths used in the spec (e.g., 1, 2, 6, 8, 9, 10, 30 bits) and providing specialized fast paths.
  • Consider using nint/nuint for indices and shifts to better match JIT expectations on 64-bit hardware.
  • Investigate use of System.Runtime.Intrinsics or Vector128/Vector256 to decode multiple 6-bit characters in parallel when reading fields that span multiple AIS characters.

Impact

• Potentially substantial CPU reduction if bit extraction is confirmed to be the dominant cost; changes should be driven by micro-benchmarks due to the complexity of bit-twiddling logic.

5.2 Exception messages and range checks

Observation

• AisAsciiTo6Bits uses nested conditional operators and throws with repeated string literals for invalid ranges.
• Range checks in GetUnsignedInteger and GetSignedInteger throw ArgumentOutOfRangeException for off-end or oversized fields.

Recommendations

• If invalid input is common, consider non-throwing TryAisAsciiTo6Bits/TryGetUnsignedInteger variants returning bool + out value, and use them in hot paths that can tolerate skipping invalid messages via OnError.
• For purely defensive checks that should never trigger in production (internal invariants), you can leave the exceptions as-is; they are off the hot path in well-formed data.

Impact

• Similar to §4.4: reduces CPU overhead under noisy input at the expense of more complex control flow.

---

6. Text field parsing (NmeaAisTextFieldParser, AisStrings)

Files:

• Ais.Net/Ais/Net/NmeaAisTextFieldParser.cs
• Ais.Net/Ais/Net/AisStrings.cs

6.1 Buffer sizing and bounds

Observation

• WriteAsAscii(in Span<byte> targetBuffer) assumes targetBuffer.Length is at least CharacterCount and writes exactly targetBuffer.Length bytes.

Recommendation

• Consider documenting and/or asserting that targetBuffer.Length == CharacterCount in the primary usage pattern; if you plan to reuse larger buffers, change the loop to:

  int chars = (int)this.CharacterCount;
  for (int i = 0; i < chars; ++i)
  {
      targetBuffer[i] = this.GetAscii((uint)i);
  }

• Optionally, expose a method that writes into an IBufferWriter<byte> or returns a ReadOnlySpan<byte> view over a caller-provided buffer to better integrate with modern pipeline-based consumers.

Impact

• Mainly robustness and clarity; negligible performance effect unless mis-sized buffers are currently in use.

6.2 Character conversion table

Observation

• AisStrings.AisCharacterToAsciiValue translates AIS 6-bit characters to ASCII with a simple conditional; this is already very efficient.

Recommendation

• No change required for performance; if needed for clarity, you could precompute a 64-entry lookup table in a ReadOnlySpan<byte> and index into it, but this is unlikely to be measurably faster than the current arithmetic.

Impact

• Current implementation is appropriate; any change should not be made without benchmark evidence.

---

7. Tag block parsing (NmeaTagBlockParser)

File:

• Ais.Net/Ais/Net/NmeaTagBlockParser.cs

7.1 Parsing helpers and Utf8Parser usage

Observation

• Integer fields are parsed with Utf8Parser.TryParse over ReadOnlySpan<byte>, with careful delimiter handling via GetEnd.
• The parser uses scoped parameters for spans in helpers like ParseSentenceGrouping, which is already a modern pattern.

Recommendations

• No major changes needed; the implementation is already allocation-free and uses the fastest available parser.
• If additional tag fields are added in future, maintain the pattern of span-based, non-allocating parsing, and prefer Utf8Parser/Utf8-based APIs over Encoding-based conversions.

Impact

• This component is already in good shape from a performance perspective.

---

8. Error handling and API shape

8.1 Exception-heavy hot paths

Observation

• Across NmeaLineParser, NmeaTagBlockParser, and the message-specific parsers, invalid input is typically handled by throwing ArgumentException/ArgumentOutOfRangeException/NotSupportedException.
• In controlled environments with mostly clean data this is fine; in noisy environments (e.g., live AIS radio feeds) frequent exceptions can dominate CPU and GC time.

Recommendations

• Introduce parallel "try" APIs for hot paths, following the BCL pattern:
  • bool TryParseLine(ReadOnlySpan<byte> line, out NmeaLineParser parser, out ParseError error)
  • bool TryParseTagBlock(ReadOnlySpan<byte> source, out NmeaTagBlockParser parser, out TagBlockError error)
• Use these Try* methods in high-throughput ingestion code and reserve exception-throwing variants for public, developer-facing APIs where misuse should be clearly signaled.

Impact

• Can dramatically reduce CPU and allocation overhead when processing large amounts of partially-corrupted or malformed data.

---

9. General .NET 8–10 opportunities

9.1 Hardware and JIT-friendly coding patterns

Recommendations

• Favor nint/nuint and nint-based index arithmetic in inner loops (e.g., NmeaAisBitVectorParser) to play well with the 64-bit JIT.
• Audit hot loops for invariant computations (e.g., repeated span length or property reads) and hoist them outside loops where possible; the JIT often does this, but being explicit in the hottest areas can help.
• Consider annotating extremely hot methods with [MethodImpl(MethodImplOptions.AggressiveInlining)] where benchmarks show non-trivial benefit (e.g., small GetUnsignedInteger helpers).

9.2 Benchmarking and profiling

Recommendations

• Extend Ais.Net.Benchmarks to cover:
  • NmeaStreamParser.ParseStreamAsync end-to-end with realistic sample data from production environments.
  • Isolated micro-benchmarks for NmeaAisBitVectorParser.GetUnsignedInteger, NmeaLineParser construction, and fragmented message reassembly.
• Run these under current runtimes with PGO (Profile Guided Optimization) enabled to allow the JIT to specialize hot paths automatically.

Impact

• Ensures that future performance work is guided by measurements rather than intuition, and leverages the full capabilities of the modern .NET JIT and runtime.

---

10. Summary

• The Ais.Net library already uses a highly efficient, low-allocation design that is well-suited to high-throughput AIS parsing.
• The highest-value next steps are: (1) simplifying target frameworks to modern .NET only, (2) revisiting the custom Pipe/I/O strategy, (3) reducing redundant parsing and exception use on hot paths, and (4) benchmarking NmeaAisBitVectorParser and fragmentation handling under real workloads.
• Most other suggestions are micro-optimizations that should be pursued only if confirmed by benchmarks to matter in your specific deployment scenarios.

Opus 4.5

Solutions Performance Improvement Review (December 2025)

This document captures a targeted performance review of the code under Solutions, with concrete modernization actions to keep the pipeline “zero allocation” friendly on .NET 10/C# 14 era runtimes. The review prioritizes hot paths (stream ingestion, parsing, fragment reassembly) and supporting assets (benchmarks, build configuration).

Quick wins (highest ROI first)

#	Area	File / Location	Issue	Recommendation	Expected impact
1	Targeting & packaging	Ais.Net/Ais.Net.csproj lines 14‑24; Common.*.proj	Library still targets only netstandard2.x, pulling in System.IO.Pipelines 4.7.5 and System.Memory shims. Modern JIT/SIMD, CollectionsMarshal, ValueStringBuilder, NativeAOT, etc. are unavailable.	Multi-target net10.0;net8.0;netstandard2.1;netstandard2.0 and conditionally light up modern intrinsics (#if NET8_0_OR_GREATER). Drop legacy package references where the runtime already provides them.	Unlocks new BCL intrinsics, reduces package graph, and enables shipping NativeAOT-optimized assets without forking the codebase.
2	Stream ingestion & I/O	Ais.Net/Ais/Net/NmeaStreamParser.cs lines 108‑255	Manual Pipe bridge reads with FileStream bufferSize 1, Environment.TickCount, and a fixed 1 kB splitLineBuffer. This causes excess syscalls, bounded line lengths, and extra parsing passes for multi-segment sequences.	Use FileStreamOptions (async + SequentialScan) plus PipeReader.Create(stream, new StreamPipeReaderOptions(bufferSize: 4 MB, minimumReadSize: 128 kB)). Replace splitLineBuffer with pooled/stack spans sized to actual line length, and switch timing to Stopwatch.GetTimestamp()/ValueStopwatch.	Higher throughput from fewer kernel transitions, removal of per-line heap allocations, safe handling of arbitrarily long NMEA sentences, and precise telemetry even on long-running services.
3	Fragment reassembly	Ais.Net/Ais/Net/NmeaLineToAisStreamAdapter.cs lines 81‑238	Every fragment is reparsed several times, entire NMEA lines are copied into pooled arrays, and dictionary lookups perform multiple allocations; stackalloc removal list can blow the stack under fan-in bursts.	Cache NmeaTagBlockParser per line, store only payload slices + padding, and replace dictionary logic with CollectionsMarshal.GetValueRefOrAddDefault. Use pooled ValueListBuilder<int> (or ArrayPool<int>) for aged fragment tracking.	Drops reparse cost, halves pooled memory pressure, and avoids GC pressure / stack overflows when thousands of fragments are inflight.
4	Bit-vector decoding	Ais.Net/Ais/Net/NmeaAisBitVectorParser.cs lines 26‑147; NmeaPayloadParser.cs lines 22‑45	Each field extraction reconverts ASCII → 6-bit via branchy logic and shifts at most 6 bits per loop, leading to ~5–7× more instructions than necessary.	When constructing the parser, decode the entire payload once into a Span<uint> of 6-bit values (using stackalloc up to ~256 B, else ArrayPool). Use BinaryPrimitives.ReadUInt32BigEndian/BitOperations.RotateLeft to pull up to 32 bits at once and implement sign-extension via arithmetic shifts.	Eliminates repeated ASCII decoding, enabling vectorization and measurable reductions (>20%) in CPU cycles per field-heavy message.
5	Benchmark harness	Ais.Net.Benchmarks/*.cs	Benchmark setup rewrites a 1 M line file synchronously every run and does not emit GC/improvement counters, making regressions hard to spot.	Pre-build datasets once per job (or use memory-mapped files) and wire BenchmarkDotNet EventPipeProfiler/HardwareCounters. Add scenarios that exercise multi-threaded ingestion and NativeAOT builds.	Produces more stable perf baselines and surfaces instruction/IPC deltas when applying the other optimizations.

Detailed findings

1. Target frameworks, analyzers, and packages

• Solutions/Ais.Net/Ais.Net.csproj (lines 14‑24) still targets only netstandard2.0/2.1, forcing the inclusion of System.IO.Pipelines 4.7.5 and System.Memory for legacy TFMs. This blocks the use of modern APIs such as CollectionsMarshal, System.Buffers.SearchValues, Span<T>-friendly regexes, RandomAccess.ReadAsync, or NativeAOT-compatible trimming hints.
• Recommendation:
  • Multi-target net10.0;net8.0 alongside the existing netstandard TFMs, and use <RuntimeIdentifier>-specific PublishAot profiles for deployments where latency matters.
  • Move shared analyzer/package configuration out of Common.Net.proj once per-SDK analyzers (e.g., CA.Aot) are enabled so we can enable new warnings only where supported.
  • Replace System.IO.Pipelines NuGet dependency with the in-box version for modern TFMs, while keeping the package reference only for netstandard2.0.

Impact: The compiler can now emit intrinsics (AVX‑512 on Linux, ARM64 SVE), and we reduce package restore time and dependency graph complexity.

2. Streaming and I/O hot path (NmeaStreamParser.cs)

Observed issues:

1. Lines 108‑205: ParseStreamAsync polls PipeReader.ReadAsync without ReadAtLeastAsync, resulting in tiny reads on slow disks and extra syscalls. Also, the manual ProcessBuffer repeatedly scans for \n using ReadOnlySequence.PositionOf, which walks the sequence twice.
2. Lines 79‑81: new FileStream(path, … bufferSize: 1, useAsync: true) disables user-mode buffering but increases kernel transitions. Modern .NET exposes FileStreamOptions that preserve zero-copy semantics without artificially shrinking the buffer.
3. Line 116: byte[] splitLineBuffer = new byte[1000]; is allocated per call and fails on >1 kB sentences, requiring reallocation (and silently truncating when line.Length > 1000).
4. Lines 131‑200: timing uses Environment.TickCount, which wraps every 49 days and lacks resolution; progress reports will become negative on busy daemons.
5. Lines 217‑235: the custom PipeWriter loop calls writer.GetMemory() with unspecified size, leading to 4 kB acquisitions on most platforms and inflated flush frequency.

Recommendations:

• Replace the manual pipe with PipeReader.Create(stream, new StreamPipeReaderOptions(bufferSize: 4 * 1024 * 1024, minimumReadSize: 128 * 1024, leaveOpen: true)) and use SequenceReader<byte> to parse lines without copying, drastically reducing branch mispredictions.
• Use FileStreamOptions (async + SequentialScan) or RandomAccess.ReadAsync to batch filesystem IO while still avoiding double-buffering.
• Replace the fixed splitLineBuffer with Span<byte> lineBuffer = line.IsSingleSegment ? line.FirstSpan : ArrayPool<byte>.Shared.Rent((int)line.Length) plus try/finally return, or adopt ValueListBuilder<byte> to keep short lines on the stack.
• Switch timing to ValueStopwatch/Stopwatch.GetTimestamp() and compute throughput via Stopwatch.Frequency, eliminating wrap-around bugs.
• Request larger chunks from the PipeWriter (e.g., writer.GetMemory(128 * 1024)) and use ReadOnlySequence<byte>.Slice with SequencePosition next = readerBuffer.GetPosition(1, eol) to avoid re-computing offsets.

Impact: On modern SSDs and high-latency network streams, these changes reduce kernel calls by ~50%, allow arbitrarily long NMEA sentences, and provide accurate telemetry for adaptive throttling.

3. Sentence parsing (NmeaLineParser.cs)

• Static ASCII sentinels (VdmAscii, VdoAscii) are stored as byte[] built via Encoding.ASCII, incurring a static constructor and GC pinning. Using private static ReadOnlySpan<byte> VdmAscii => "VDM"u8; avoids both.
• TagBlock property (line 235) allocates a new NmeaTagBlockParser on every access. In NmeaLineToAisStreamAdapter we access it twice per line (lines 94‑105), meaning duplicate parsing and checksum validation.
• GetSingleDigitField (lines 249‑273) rejects multi-digit fragment counts. The AIS spec allows up to 9, but third-party data sets often emit 10+, causing avoidable exceptions and re-parses.
• The parser repeatedly calls remainingFields.IndexOf((byte)',')), rescanning the same span. Using SearchValues<byte> or Utf8Parser over a SequenceReader<byte> can reduce branch mispredictions and take advantage of AVX2.

Recommendations:

• Cache a NmeaTagBlockParser inside NmeaLineParser (e.g., private readonly NmeaTagBlockParser? tagBlock;) so consumers do not re-parse.
• Replace digit parsing with Utf8Parser.TryParse on ReadOnlySpan<byte> to accept multi-digit counts while remaining allocation-free.
• Adopt SearchValues<byte> for delimiter scans so the JIT can vectorize them automatically.

Impact: Eliminates redundant work during fragment-heavy loads and removes latent incompatibilities with newer AIS feeds.

4. Fragment reassembly (NmeaLineToAisStreamAdapter.cs)

Issues:

1. Lines 89‑187: Each fragment copies the whole NMEA line into a pooled array and creates NmeaLineParser instances multiple times—once when first received, again while summing payload lengths, and again during reassembly.
2. Lines 196‑236: fragmentGroupIdsToRemove uses stackalloc int[this.messageFragments.Count]. Under high traffic, the dictionary can reach thousands of entries and blow the stack (especially on macOS where the guard page is small).
3. Dictionary usage does two lookups (TryGetValue / Add). .NET 8 introduced CollectionsMarshal.GetValueRefOrAddDefault, which can mutate entries in-place without allocations.
4. parsedLine.TagBlock is read twice (lines 92‑101), recreating the parser each time (see §3).
5. When discarding aged fragments (lines 208‑236), the code finds the “last non-null entry” by looping backward and assumes at least one fragment exists, which throws if the group never received any payload. Aside from correctness, the work re-parses the fragment again to produce error text.

Recommendations:

• Store only payload slices: rent buffers sized to parsedLine.Payload.Length, copy just payload bytes, and track padding per fragment. When all fragments arrive, stitch payload spans via IBufferWriter<byte> without re-parsing.
• Use CollectionsMarshal.GetValueRefOrAddDefault (net8+) to fetch or create FragmentedMessage without double hashing. For netstandard builds, leave the current path via #if.
• Replace stackalloc removal list with ArrayPool<int>.Shared.Rent(Math.Min(messageFragments.Count, 1024)) or a reusable ValueListBuilder<int>.
• Cache NmeaTagBlockParser up-stack so we do not rehydrate it per property access.
• Add diagnostic counters for dropped fragments so operations teams can react before stacks build up.

Impact: Cuts fragment reassembly CPU cost roughly in half, mitigates high-memory workloads, and prevents stack overflows during fragment storms.

5. Bit-vector & payload decoding (NmeaAisBitVectorParser.cs, NmeaPayloadParser.cs, AisStrings.cs)

• NmeaPayloadParser.AisAsciiTo6Bits (lines 37‑45) performs nested ternary checks and allocates exception strings on every invalid byte. Modern runtimes provide ArgumentOutOfRangeException.ThrowIfNegative and ThrowHelper to keep the happy path branchless.
• GetUnsignedInteger (lines 67‑138) processes at most 6 bits per loop iteration and calls AisAsciiTo6Bits for every chunk. For a 256-bit payload, this means ~43 calls even if later fields re-read the same 6-bit value.
• GetSignedInteger (lines 43‑59) recomputes sign masks; we can sign-extend via bit shifts (int shift = 32 - (int)bitCount; return ((int)value << shift) >> shift;).
• No attempt is made to leverage vectorization; each ASCII byte is decoded independently. A lookup table (ReadOnlySpan<byte> Lookup = ...) or even Vector128<byte> comparisons can translate 16 bytes at a time.

Recommendations:

• During construction, decode the payload once into a Span<uint> (6-bit values) stored either on the stack (for short payloads) or in a pooled buffer. Keep BitCount and re-use the decoded span in all Get* calls.
• Expose APIs that operate over BitReader semantics (e.g., TryReadUInt32(bitCount, out uint value) returning a ref struct), enabling consumers to sequentially advance without recomputing offsets.
• Use source-generated throw helpers (or ArgumentOutOfRangeException.ThrowIfGreaterThan) for invalid ASCII to keep the hot path branch-free.
• Consider a static ReadOnlySpan<byte> SixBitLookup => "................................0123456789:;<=>?@ABCDEFGHIJKLMNO...................PQRSTUVWXYZ[\\]^_abcdefghijklmno...................pqrstuvwxyz{|}~"u8;` to map ASCII directly.

Impact: Reduces per-field latency, enabling real-time decoding of high-density AIS data while preserving zero-allocation guarantees.

6. Downstream processors (ReadAllPositions.cs, InspectMessageType.cs)

• Each processor repeatedly calls NmeaPayloadParser.PeekMessageType, which re-validates the payload and decodes the first 6 bits for every consumer. Consider caching the type when the message is first parsed and passing it alongside the payload.
• ReadAllPositions constructs new parser structs for each message type. With multi-million message streams, that’s a lot of redundant work when consumers only need a subset of fields. Introducing specialized fast-paths (e.g., “just read lat/long + speed”) would reduce instruction count.

Recommendations: Add a lightweight metadata struct (message type, padding, predecoded NmeaAisBitVectorParser) that can be passed to processors, and expose APIs for reading subsets of fields without rebuilding parser state.

7. Benchmarks & diagnostics (Ais.Net.Benchmarks)

• GlobalSetup rewrites a 1 M line file synchronously (File.ReadAllLines + StreamWriter) every run, introducing noise and blocking the thread pool during CI. Persist the generated data as part of the repo or use memory-mapped files so that the dataset is materialized once.
• Benchmarks currently report only average time. Enable BenchmarkDotNet’s HardwareCounters (instructions, cache misses) and EventPipeProfiler to capture GC pressure.
• Add scenarios for concurrent parsing (e.g., multiple NmeaStreamParser.ParseStreamAsync tasks) and native AOT builds so regressions show up before shipping.

Impact: More reliable perf baselines and richer telemetry whenever parser changes are introduced.

8. Observability & correctness

• NmeaLineToAisStreamAdapter.FreeRentedBuffers writes to Console, which is problematic in services. Replace with structured logging/event counters so operators can monitor fragment drops without stdout parsing.
• Add System.Diagnostics.Metrics counters (lines processed, fragments dropped, average message latency) to feed OpenTelemetry. Modern .NET makes this zero-cost when no listener is attached.

---

By implementing the above, the Solutions codebase can fully leverage the capabilities of .NET 10/C# 14, minimize allocations, and keep throughput competitive on modern CPU architectures while retaining compatibility with older deployments.

Opus 4.5 inside Claude Code

Ais.Net Performance Improvements for .NET 10 / C# 14

Executive Summary

This document outlines performance improvements for the Ais.Net library, targeting the transition from .NET Standard 2.0/2.1 to .NET 10 and C# 14. The library is already well-optimized with zero-allocation parsing using ref struct and ReadOnlySpan<byte>. The improvements below leverage 6+ years of .NET runtime advancements, modern CPU intrinsics, and new language features to further enhance throughput for mission-critical AIS message processing.

Priority Classification:

• P0 (Critical): Immediate measurable throughput gains
• P1 (High): Significant improvements with moderate effort
• P2 (Medium): Good improvements, consider for next iteration
• P3 (Low): Minor optimizations or future considerations

---

1. Target Framework Modernization

Current State

<TargetFrameworks>netstandard2.1;netstandard2.0</TargetFrameworks>

Recommendation (P0)

Add modern TFMs while maintaining backwards compatibility:

<TargetFrameworks>net10.0;net9.0;net8.0;netstandard2.1;netstandard2.0</TargetFrameworks>

Rationale:

• Unlocks all optimizations below via #if NET8_0_OR_GREATER directives
• .NET 8+ has significantly improved JIT codegen, especially for Span operations
• Allows use of hardware intrinsics, SearchValues, FrozenDictionary, etc.
• Users on modern runtimes get automatic performance gains

---

2. SIMD/Vectorization Opportunities

2.1 AIS ASCII to 6-Bit Conversion (P0)

File: NmeaPayloadParser.cs:37-45

Current Implementation:

internal static byte AisAsciiTo6Bits(byte c) => (byte)(c < 48
    ? throw new ArgumentOutOfRangeException(...)
    : (c < 88
        ? c - 48
        : (c < 96
            ? throw new ArgumentOutOfRangeException(...)
            : (c < 120
                ? c - 56
                : throw new ArgumentOutOfRangeException(...)))));

Proposed Improvement:

#if NET8_0_OR_GREATER
// Lookup table approach - branch-free, cache-friendly
private static ReadOnlySpan<byte> AisDecodeLut => new byte[128]
{
    // Pre-computed lookup: invalid = 0xFF, valid = decoded value
    // Indices 48-87: value - 48
    // Indices 96-119: value - 56
    // All others: 0xFF (invalid)
};

[MethodImpl(MethodImplOptions.AggressiveInlining)]
internal static byte AisAsciiTo6Bits(byte c)
{
    byte result = c < 128 ? AisDecodeLut[c] : (byte)0xFF;
    if (result == 0xFF)
        ThrowInvalidPayloadCharacter(c);
    return result;
}

// Vectorized batch conversion for SIMD-enabled paths
internal static void AisAsciiTo6BitsBatch(ReadOnlySpan<byte> source, Span<byte> dest)
{
    if (Vector256.IsHardwareAccelerated && source.Length >= Vector256<byte>.Count)
    {
        // Process 32 bytes at a time using AVX2
        // Range check and convert in parallel
    }
    // Scalar fallback
}
#endif

Expected Impact: 2-4x throughput for payload decoding on AVX2-capable hardware.

---

2.2 Bit Vector Extraction (P1)

File: NmeaAisBitVectorParser.cs:67-138

Current Implementation:
The GetUnsignedInteger method processes bits character-by-character in a loop.

Proposed Improvements:

1. Use BitOperations class (.NET 5+)

#if NET5_0_OR_GREATER
using System.Numerics;

// Replace manual bit manipulation with hardware-accelerated operations
int leadingZeros = BitOperations.LeadingZeroCount(value);
int trailingZeros = BitOperations.TrailingZeroCount(value);
uint rotated = BitOperations.RotateLeft(value, shift);
#endif

2. Pre-decode entire payload to 6-bit values

// For messages accessed multiple times, pre-decode once
Span<byte> decoded = stackalloc byte[ascii.Length];
AisAsciiTo6BitsBatch(ascii, decoded);
// Then extract bits from contiguous 6-bit values

3. Optimized extraction for common field sizes (6, 8, 9, 10, 12, 27, 28, 30 bits)

// Specialized fast paths for frequently-used bit widths
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public uint GetUnsigned6Bits(uint bitOffset)
{
    // Single character extraction - no loop needed
    int charOffset = (int)(bitOffset / 6);
    int localOffset = (int)(bitOffset % 6);
    if (localOffset == 0)
        return NmeaPayloadParser.AisAsciiTo6Bits(this.ascii[charOffset]);
    // Handle cross-character case
}

Expected Impact: 20-40% reduction in per-field extraction time.

---

2.3 SearchValues for Delimiter Scanning (P0)

File: NmeaLineParser.cs, NmeaTagBlockParser.cs, NmeaStreamParser.cs

Current Implementation:

int nextComma = remainingFields.IndexOf((byte)',');
int tagBlockEndIndex = line.Slice(1).IndexOf(TagBlockMarker);

Proposed Improvement (.NET 8+):

#if NET8_0_OR_GREATER
private static readonly SearchValues<byte> Delimiters = SearchValues.Create(","u8);
private static readonly SearchValues<byte> LineEndOrTagBlock = SearchValues.Create("\n\r\\"u8);

// Single scan for multiple delimiters
int delimiterIndex = span.IndexOfAny(LineEndOrTagBlock);
#endif

Expected Impact: 15-30% faster delimiter scanning, especially for long lines.

---

3. Memory Allocation Elimination

3.1 UTF-8 String Literals (P0)

File: NmeaLineParser.cs:17-18

Current Implementation:

private static readonly byte[] VdmAscii = Encoding.ASCII.GetBytes("VDM");
private static readonly byte[] VdoAscii = Encoding.ASCII.GetBytes("VDO");

Proposed Improvement (C# 11+):

#if NET7_0_OR_GREATER
private static ReadOnlySpan<byte> VdmAscii => "VDM"u8;
private static ReadOnlySpan<byte> VdoAscii => "VDO"u8;
#else
private static readonly byte[] VdmAscii = Encoding.ASCII.GetBytes("VDM");
private static readonly byte[] VdoAscii = Encoding.ASCII.GetBytes("VDO");
#endif

Rationale:

• Zero heap allocation - data stored directly in assembly
• Compiler-verified UTF-8 encoding
• ReadOnlySpan<byte> returned from ROM

---

3.2 Stream Parser Buffer Pooling (P1)

File: NmeaStreamParser.cs:116

Current Implementation:

byte[] splitLineBuffer = new byte[1000];

Proposed Improvement:

#if NET6_0_OR_GREATER
// Use ArrayPool for the split line buffer
byte[] splitLineBuffer = ArrayPool<byte>.Shared.Rent(1024);
try
{
    // ... processing
}
finally
{
    ArrayPool<byte>.Shared.Return(splitLineBuffer);
}
#endif

Note: For very hot paths, consider stackalloc with a reasonable limit:

Span<byte> splitLineBuffer = stackalloc byte[1024];

---

3.3 FrozenDictionary for Fragment Tracking (P2)

File: NmeaLineToAisStreamAdapter.cs:21

Current Implementation:

private readonly Dictionary<int, FragmentedMessage> messageFragments = new Dictionary<int, FragmentedMessage>();

Proposed Improvement:
While fragments are dynamic, consider:

1. Pre-sized Dictionary with expected capacity
2. Alternative data structure for small counts (fragments are typically 1-9):

#if NET8_0_OR_GREATER
// For small fragment counts, linear search may be faster
private FragmentedMessage[] fragmentArray = new FragmentedMessage[10];
private int fragmentCount = 0;
#endif

---

3.4 ThrowHelper Pattern for Exception Hot Paths (P0)

Files: All parser files

Current Implementation:

throw new ArgumentOutOfRangeException("Payload characters must be in range 48-87 or 96-119");
throw new ArgumentException("Invalid data. Expected '!' at sentence start");

Proposed Improvement:

internal static class ThrowHelpers
{
    [DoesNotReturn]
    [MethodImpl(MethodImplOptions.NoInlining)]
    public static void ThrowInvalidPayloadCharacter()
        => throw new ArgumentOutOfRangeException("Payload characters must be in range 48-87 or 96-119");

    [DoesNotReturn]
    [MethodImpl(MethodImplOptions.NoInlining)]
    public static void ThrowInvalidSentenceStart()
        => throw new ArgumentException("Invalid data. Expected '!' at sentence start");

    // ... other exception helpers
}

Rationale:

• Keeps hot path methods small (better inlining)
• Moves exception construction code out of hot path
• [DoesNotReturn] helps JIT understand control flow
• Avoids string allocation until exception is actually thrown

---

4. Modern C# Language Features

4.1 Primary Constructors (C# 12+) (P3)

File: NmeaTagBlockSentenceGrouping.cs

Current:

public readonly struct NmeaTagBlockSentenceGrouping
{
    public NmeaTagBlockSentenceGrouping(int sentenceNumber, int sentencesInGroup, int groupId)
    {
        this.SentenceNumber = sentenceNumber;
        this.SentencesInGroup = sentencesInGroup;
        this.GroupId = groupId;
    }

    public int GroupId { get; }
    public int SentenceNumber { get; }
    public int SentencesInGroup { get; }
}

Proposed:

public readonly struct NmeaTagBlockSentenceGrouping(int sentenceNumber, int sentencesInGroup, int groupId)
{
    public int GroupId { get; } = groupId;
    public int SentenceNumber { get; } = sentenceNumber;
    public int SentencesInGroup { get; } = sentencesInGroup;
}

---

4.2 Collection Expressions (C# 12+) (P3)

File: NmeaLineParser.cs

Where applicable, replace array initializations:

// Current
private static readonly byte[] VdmAscii = Encoding.ASCII.GetBytes("VDM");

// With collection expressions (where not using u8 literals)
private static readonly byte[] SomeArray = [0x01, 0x02, 0x03];

---

4.3 Pattern Matching Improvements (P2)

File: NmeaLineParser.cs:90-118

Current (switch expression is good, but can be enhanced):

this.AisTalker = talkerFirstChar switch
{
    (byte)'A' => talkerSecondChar switch { ... },
    (byte)'B' => talkerSecondChar switch { ... },
    // ...
};

Alternative using tuple patterns:

this.AisTalker = (talkerFirstChar, talkerSecondChar) switch
{
    ((byte)'A', (byte)'I') => TalkerId.MobileStation,
    ((byte)'A', (byte)'B') => TalkerId.BaseStation,
    ((byte)'A', (byte)'D') => TalkerId.DependentBaseStation,
    // ... flattened structure, potentially better JIT optimization
    _ => ThrowHelpers.ThrowUnrecognizedTalkerId<TalkerId>()
};

---

4.4 Required Members (C# 11+) (P3)

File: NmeaParserOptions.cs

#if NET7_0_OR_GREATER
public class NmeaParserOptions
{
    public bool ThrowWhenTagBlockContainsUnknownFields { get; init; } = true;
    public int MaximumUnmatchedFragmentAge { get; init; } = 8;
}
#endif

---

5. Async and I/O Improvements

5.1 High-Precision Timing (P1)

File: NmeaStreamParser.cs:109-110

Current:

int ticksAtStart = Environment.TickCount;

Proposed:

#if NET7_0_OR_GREATER
long ticksAtStart = Stopwatch.GetTimestamp();
// Later:
double elapsedMs = Stopwatch.GetElapsedTime(ticksAtStart).TotalMilliseconds;
#else
int ticksAtStart = Environment.TickCount;
#endif

Rationale: Stopwatch.GetTimestamp() provides nanosecond precision on modern systems.

---

5.2 IAsyncEnumerable Support (P2)

New API Addition:

#if NET8_0_OR_GREATER
public static async IAsyncEnumerable<NmeaLineParser> ParseLinesAsync(
    Stream stream,
    [EnumeratorCancellation] CancellationToken cancellationToken = default)
{
    // Yield parsed lines as they become available
    // Allows consumers to use LINQ operators, filtering, etc.
}
#endif

---

5.3 RandomAccess for File I/O (P2)

File: NmeaStreamParser.cs:79

Current:

using var file = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite, bufferSize: 1, useAsync: true);

Alternative for certain scenarios:

#if NET6_0_OR_GREATER
using SafeFileHandle handle = File.OpenHandle(path, FileMode.Open, FileAccess.Read, FileShare.Read, FileOptions.Asynchronous | FileOptions.SequentialScan);
// Use RandomAccess.ReadAsync for specific offsets
// Or continue with FileStream but with optimized options
#endif

---

5.4 ConfigureAwait Improvements (P3)

.NET 8+ consideration:

// For library code, consider adding ConfigureAwait(ConfigureAwaitOptions.ForceYielding)
// in specific scenarios where you want to ensure yielding

---

6. Bit Manipulation Optimizations

6.1 Branchless Minimum (P1)

File: NmeaAisBitVectorParser.cs:89

Current:

result <<= Math.Min(6, remainingBits);

Proposed:

// Branchless minimum for power-of-2 range
int shift = remainingBits & ~(remainingBits >> 31); // Handle negative (won't happen here)
shift = shift > 6 ? 6 : shift; // Compiler may optimize to cmov

Or use Math.Min and trust the JIT (modern .NET JIT often emits branchless code for simple Math.Min patterns).

---

6.2 Sign Extension Optimization (P1)

File: NmeaAisBitVectorParser.cs:43-58

Current:

public int GetSignedInteger(uint bitCount, uint bitOffset)
{
    int result = (int)this.GetUnsignedInteger(bitCount, bitOffset);
    int sbitCount = (int)bitCount;
    int msb = 1 << (sbitCount - 1);
    bool isNegative = (result & msb) != 0;
    if (isNegative)
    {
        const int allOnesExceptLsb = -2;
        int signBits = allOnesExceptLsb << (sbitCount - 1);
        result |= signBits;
    }
    return result;
}

Proposed (branchless sign extension):

#if NET6_0_OR_GREATER
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public int GetSignedInteger(uint bitCount, uint bitOffset)
{
    uint unsigned = this.GetUnsignedInteger(bitCount, bitOffset);
    int shift = 32 - (int)bitCount;
    // Arithmetic right shift propagates sign bit
    return (int)(unsigned << shift) >> shift;
}
#endif

Expected Impact: Eliminates branch in sign extension, ~10-15% faster for signed integer fields (latitude, longitude, rate of turn).

---

7. Span and Memory Optimizations

7.1 SequenceReader for Buffer Parsing (P2)

File: NmeaStreamParser.cs ProcessBuffer method

Consideration:

#if NET6_0_OR_GREATER
var reader = new SequenceReader<byte>(remainingSequence);
while (reader.TryReadTo(out ReadOnlySpan<byte> line, (byte)'\n'))
{
    // Process line
}
#endif

Note: Current implementation is already efficient; SequenceReader may add overhead for simple newline scanning.

---

7.2 Span Slicing in Loops (P2)

File: NmeaAisTextFieldParser.cs:67-73

Current:

public void WriteAsAscii(in Span<byte> targetBuffer)
{
    for (int i = 0; i < targetBuffer.Length; ++i)
    {
        targetBuffer[i] = this.GetAscii((uint)i);
    }
}

Proposed (batch processing):

public void WriteAsAscii(in Span<byte> targetBuffer)
{
    uint charCount = this.CharacterCount;
    for (uint i = 0; i < charCount; ++i)
    {
        uint bitIndexInField = i * 6;
        byte aisValue = (byte)this.bits.GetUnsignedInteger(6, this.bitOffset + bitIndexInField);
        targetBuffer[(int)i] = AisStrings.AisCharacterToAsciiValue(aisValue);
    }
}

Further optimization: inline GetAscii logic to avoid per-character method call overhead.

---

8. JIT and Codegen Hints

8.1 Aggressive Inlining Attributes (P1)

Add [MethodImpl(MethodImplOptions.AggressiveInlining)] to:

• AisAsciiTo6Bits
• GetUnsignedInteger (for small bit counts)
• GetBit
• AisCharacterToAsciiValue
• Property getters on parser structs

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public uint MessageType => this.bits.GetUnsignedInteger(6, 0);

---

8.2 SkipLocalsInit (P2)

For hot allocation paths:

#if NET5_0_OR_GREATER
[SkipLocalsInit]
public static async Task ParseStreamAsync(...)
{
    // stackalloc buffers won't be zero-initialized
}
#endif

Caution: Only use where you're certain all locals are written before read.

---

8.3 Suppress GC Transitions (P3)

For extremely hot paths with no managed allocations:

#if NET7_0_OR_GREATER
[SuppressGCTransition]
[UnmanagedCallersOnly]
// For native interop scenarios only
#endif

---

9. API Additions for Modern Consumers

9.1 Generic Math Support (P3)

File: New IAisPositionReport interface

#if NET7_0_OR_GREATER
public interface IAisPositionReport<TSelf> where TSelf : IAisPositionReport<TSelf>
{
    static abstract int GetLatitude10000thMins(in TSelf report);
    static abstract int GetLongitude10000thMins(in TSelf report);
}
#endif

---

9.2 Utf8JsonWriter Support (P2)

#if NET6_0_OR_GREATER
public static class AisJsonExtensions
{
    public static void WriteAsJson(this NmeaAisPositionReportClassAParser parser, Utf8JsonWriter writer)
    {
        writer.WriteStartObject();
        writer.WriteNumber("mmsi"u8, parser.Mmsi);
        writer.WriteNumber("lat"u8, parser.Latitude10000thMins);
        writer.WriteNumber("lon"u8, parser.Longitude10000thMins);
        // ... zero-allocation JSON serialization
        writer.WriteEndObject();
    }
}
#endif

---

10. Benchmarking Recommendations

10.1 Update Benchmark Project

<TargetFrameworks>net10.0;net9.0;net8.0;net6.0</TargetFrameworks>

10.2 Key Benchmarks to Add

1. Payload decoding throughput (bytes/second for AisAsciiTo6Bits)
2. Bit extraction throughput (operations/second for GetUnsignedInteger)
3. Line parsing throughput (lines/second for NmeaLineParser construction)
4. Memory allocation profile (bytes allocated per message)
5. Cold vs warm path performance (first message vs steady-state)

10.3 BenchmarkDotNet Configuration

[MemoryDiagnoser]
[DisassemblyDiagnoser(maxDepth: 3)]
[Config(typeof(MultiTfmConfig))]
public class ParsingBenchmarks
{
    // Compare across TFMs
}

---

11. Implementation Priority Matrix

Improvement	Priority	Effort	Impact	Breaking Change
Add net10.0 TFM	P0	Low	High	No
UTF-8 string literals	P0	Low	Medium	No
ThrowHelper pattern	P0	Medium	Medium	No
SearchValues for delimiters	P0	Medium	High	No
AisAsciiTo6Bits lookup table	P0	Medium	High	No
Branchless sign extension	P1	Low	Medium	No
AggressiveInlining attributes	P1	Low	Medium	No
High-precision timing	P1	Low	Low	No
Bit extraction fast paths	P1	High	High	No
ArrayPool for buffers	P1	Medium	Medium	No
SIMD batch conversion	P1	High	Very High	No
IAsyncEnumerable API	P2	Medium	Medium	No (additive)
SequenceReader usage	P2	Medium	Low	No
Primary constructors	P3	Low	None	No
Generic math interfaces	P3	High	Low	No (additive)

---

12. Migration Strategy

Phase 1: Foundation

1. Add modern TFMs to project
2. Implement #if conditional compilation structure
3. Add ThrowHelper pattern
4. Add UTF-8 string literals

Phase 2: Core Optimizations

1. Implement lookup table for AIS ASCII conversion
2. Add SearchValues for delimiter scanning
3. Implement branchless sign extension
4. Add AggressiveInlining attributes

Phase 3: Advanced Optimizations

1. Implement SIMD batch conversion
2. Add specialized bit extraction paths
3. Optimize text field parsing
4. Profile and iterate

Phase 4: API Enhancements

1. Add IAsyncEnumerable support
2. Add Utf8JsonWriter extensions
3. Consider source generators for parser boilerplate

---

13. Risks and Mitigations

Risk	Mitigation
Regression in netstandard2.0	Maintain separate code paths with #if
SIMD code complexity	Thoroughly benchmark; fall back to scalar
Increased binary size	Consider separate packages for modern TFMs
Behavioral changes	Comprehensive test coverage before/after

---

14. Conclusion

The Ais.Net library has an excellent foundation with its zero-allocation ref struct design. The improvements outlined here can provide:

• 15-30% improvement from SearchValues and UTF-8 literals
• 20-40% improvement from optimized bit extraction
• 2-4x improvement in payload decoding with SIMD (AVX2 hardware)
• Better code maintainability with modern C# features

These improvements maintain full backwards compatibility through conditional compilation while giving users on modern .NET runtimes significant performance gains for their mission-critical AIS processing workloads.

---

Document Version: 1.0
Analysis Date: December 2024
Target: .NET 10 / C# 14

[idg10]

Now GPT 5.2 as well:

Performance modernization guide (2025) – Solutions/

Last updated: 2025-12-13T07:27:01.178Z

Scope: Solutions/Ais.Net (core library) and Solutions/Ais.Net.Benchmarks (measurement harness). No code changes are made by this document.

---

1) Priorities (what to do next)

P0 — correctness + throughput

1. Fragment pooled-buffer length correctness (NmeaLineToAisStreamAdapter)

   • Track the actual copied length for rented ArrayPool<byte> buffers and always slice to it (never parse the full array).
   • Outcome: fixes incorrect parsing from trailing garbage bytes and reduces wasted CPU.

2. Remove fixed-size splitLineBuffer = new byte[1000] (NmeaStreamParser)

   • Replace with a growable pooled buffer or parse directly from ReadOnlySequence<byte>.
   • Outcome: correct handling of long multi-segment lines (no truncation/reassembly failures).

3. Add a modern “fast lane” TFM

   • Add net10.0 alongside netstandard2.0/2.1.
   • Outcome: higher throughput / lower allocations on modern runtimes without dropping compatibility.

P1 — sustained throughput / allocation reduction

4. Eliminate incidental allocations + side-effects in library code

   • Remove LINQ usage in cleanup paths and avoid Console.WriteLine inside library code.
   • Outcome: lower allocations and more predictable throughput.

5. Avoid repeated work in fragment reassembly

   • Parse fragments once and store derived metadata (payload lengths/padding/offsets).
   • Outcome: fewer passes over fragment bytes → lower CPU.

6. Modernize pipelines usage for net10

   • Prefer PipeReader.Create(stream, new StreamPipeReaderOptions(...)) on net10.0 and tune via benchmarks.
   • Outcome: better sustained throughput with fewer copies on IO-heavy workloads.

P2 — micro-optimizations (only after P0/P1 are proven)

7. Replace Unicode helpers with ASCII byte checks (e.g., char.IsDigit → b >= '0' && b <= '9').
8. Replace Encoding.ASCII.GetBytes("VDM") / "VDO" with "VDM"u8 / "VDO"u8 spans.
9. Consider table-based AIS 6-bit decode if profiles show it’s hot.

---

2) Compatibility strategy (keep reach, add performance)

Recommended:

• Library targets: netstandard2.0;netstandard2.1;net10.0

Guidance:

• Use #if NET10_0_OR_GREATER only for surgical hot-path improvements.
• Treat netstandard2.0 as the compatibility surface; don’t let it dictate the optimal algorithm for net10.0.

---

3) Hotspot notes (code-level)

3.1 NmeaStreamParser

• Timing/metrics: prefer Stopwatch.GetTimestamp() over Environment.TickCount for monotonic, high-resolution timing.
• Noisy feeds: if exceptions show up in profiles, consider adding a non-throwing TryParse fast path and benchmark it.

3.2 NmeaLineToAisStreamAdapter

• Modern dictionary paths (net10 only): consider CollectionsMarshal.GetValueRefOrAddDefault only if benchmarks show it matters.

---

4) SIMD / hardware intrinsics (optional)

SIMD/intrinsics are worth it only if profiling shows your time is dominated by byte scanning (delimiters/checksum/validation) rather than the bitfield extraction. The safest approach is: (1) keep a scalar implementation as the reference, (2) add a vectorized fast path behind runtime checks, (3) verify identical behavior with fuzzed/corrupted input, and (4) benchmark end-to-end.

Where it most plausibly helps:

• delimiter scanning (,, \n, \r, *, \\)
• checksum calculation (NMEA XOR)
• ASCII validation/classification

Implementation guidance:

• Prefer BCL primitives first (IndexOf, PositionOf, etc. are already highly optimized).
• Prefer System.Numerics.Vector<T> first for cross-platform benefit.
• Only use System.Runtime.Intrinsics.* where proven by benchmarks.
• Always gate (Vector.IsHardwareAccelerated, Sse2/Avx2.IsSupported) and keep scalar fallback.
• Keep SIMD code isolated in small internal helpers.

---

5) Benchmarking recommendations (single consolidated section)

This section includes all benchmark improvement guidance, including project-specific findings for Solutions/Ais.Net.Benchmarks.

5.1 Make benchmarks measure what you intend

• Separate end-to-end vs parser-only:

  • Keep at least one benchmark that measures real ParseFileAsync throughput (includes file IO + pipelines + parsing).
  • Add a parser-only benchmark that removes IO noise by loading test bytes once and parsing from an in-memory source (e.g., MemoryStream), so parser changes don’t get masked by storage/page-cache variance.

• Avoid generating huge files inside benchmarks when possible:

  • Today, GlobalSetup generates Ais1000000Lines.nm4 by repeating the 1k dataset 1000× and writing to disk.
  • Prefer either (a) pre-generated datasets checked into test assets, or (b) looping the parse over the same in-memory dataset N times inside the benchmark, rather than writing a giant file.

• Don’t allow “work to disappear”:

  • Ensure benchmark work is consumed: return a checksum/aggregate (e.g., sum of MMSIs/types/lat/long) and validate it occasionally.

5.2 Fix benchmark harness issues in Ais.Net.Benchmarks

• Remove console output from benchmark hot paths:

  • InspectMessageType.OnError calls Console.WriteLine(error). Any error will dominate runtime and destroy measurement fidelity.
  • Record error counts in-memory instead.

• Reset state per iteration (avoid cross-iteration pollution):

  • Current processors are static singletons (private static readonly ... Processor = new ...). Their counters/sums accumulate across BenchmarkDotNet iterations.
  • Use instance fields per benchmark class and reset in [IterationSetup] (or reinstantiate processors) so each iteration is comparable.

• Path robustness:

  • Benchmarks assume TestData/... relative to the current working directory.
  • Resolve paths relative to the assembly location or the BDN artifacts directory to avoid “works on my machine” effects.

5.3 Cover realistic workload distributions

Add scenarios/parameters (via [Params]) to represent:

• fragmented-heavy mixes (type 5/type 24) to stress NmeaLineToAisStreamAdapter
• tag-block-heavy data
• long lines / multi-segment behavior
• noisy/corrupted inputs (bad checksum, truncation) to quantify exception cost and validate tolerant parsing modes

Avoid only repeating the same 1000 lines; repetition can create unrealistically stable branch patterns and cache locality.

5.4 Make results comparable across runtimes and machines

• Run explicit runtime jobs:

  • The benchmark project targets net8.0;net9.0;net10.0, but the config uses Job.Default.
  • Add separate jobs per target/runtime so output is an explicit net8 vs net10 comparison.

• Always record allocations:

  • Keep MemoryDiagnoser enabled and treat Allocated (B/op) as a primary KPI alongside throughput.

• Stabilize iteration settings:

  • Use enough warmup/measurement iterations to reduce noise.
  • Compare medians across multiple runs.

5.5 Regression gating workflow

• Store benchmark artifacts/results and compare deltas per PR.
• Gate on:
  • messages/sec (or lines/sec)
  • allocations (B/op)
• Require explicit approval for regressions beyond an agreed threshold.

---

6) Safe rollout checklist (mission critical)

For each perf PR:

• Baseline captured on the same dataset and machine class.
• Specs/tests pass.
• End-to-end benchmark + parser-only benchmark both run.
• Throughput and allocation deltas recorded.
• Rollback plan stated.

[mwadams]

What prompt was used to perform the analysis?

[HowardvanRooijen]

I can't remember exactly as it was generated over a month ago. But it was something along the lines of:

This codebase was designed 6 years ago to be high performance and zero allocation against .NET Core 2.1. While we have seen substantial performance improvements with each new version of the .NET runtime, we have not made any code changes to take advantages of new APIs or language features which have been added in all the versions since release. Do a comprehensive code review and suggest performance improvements, design changes, alternative types, new APIs which may take advantage of improved modern hardware support (SIMD, NPU, GPU, multi-core) to improve performance, including new features available in .NET 10 and C# 14