Feature request: ordered/sorted collections (+ reminder: NextGen SIMD scanner not wired in)

[Stemonik]

Two small things from real use, bundled into one note. Happy to contribute both
via PR (same flow as #150 / #151) if you're open to it.

1) Collections: an ordered / sorted dictionary (and sorted set)

Dext.Collections already covers a lot — IList<T> (with Sort(comparer) +
BinarySearch), IDictionary<K,V>, IConcurrentDictionary<K,V>,
IFrozenDictionary<K,V>, IHashSet<T>, stack/queue. What's missing is a
dictionary/set that preserves an order as a first-class type. Two flavors,
both currently absent (grep on sorted/ordered/tree/skiplist is empty):

• IOrderedDictionary<K,V> — .NET-style / LinkedHashMap: O(1) lookup +
  iteration in insertion order. This is the one we hit most: build an index
  over a result set, then both "does key X exist?" (O(1)) and "walk them in the
  order they came in" without a second sort.
• ISortedDictionary<K,V> (tree/skiplist) — iteration/lookup in key order,
  O(log n). Plus the natural complement ISortedSet<T> (today only the
  unordered IHashSet<T> exists).

What we do not need (already covered): key-ordered iteration over a list is
IList.Sort + BinarySearch; O(1) membership is IDictionary.ContainsKey /
TryGetValue. Only the ordered/sorted dictionary/set as a type is the gap.

Our current bridge is a tiny TOrderedIndex<TKey,T> wrapper (a TList for order

• an IDictionary for lookup). It works, but it'd be cleaner as a native Dext
  collection alongside the others. If useful, I can PR an IOrderedDictionary<K,V>
  (insertion-order, the higher-value one) first, then a sorted variant.

2) NextGen JSON — reminder: the SIMD scanner is still not wired in

Just a reminder, not a re-open. From the earlier benchmark note (reply26) + the
FindKey scalar PR (#151, merged — thanks): the SSE4.2 structural scanner
TNextGenJsonParser.ScanStructural_SSE42 is defined but never called — the
parser (ScanString / whitespace skipping) still runs fully scalar. That's why
parse-only isn't yet beating the mature engine despite the zero-alloc win. The
read path improved (our scalar FindKey + your >64-key hash table), but the
parse path is unchanged.

Pulling main on 2026-07-20 (HEAD 6e54e4b0) confirms it's still dead code — the
only NextGen change since is the Linux compile guard on the asm
({$IFDEF CPUX64} → {$IF CPUX64 and MSWINDOWS}). Wiring the SIMD scanner into
the parse loop (or dropping it if superseded) is the missing piece to make NextGen
win on parse-heavy workloads. Not urgent for us (we use the fork directly in the
hot path); flagging so it doesn't get lost.

Thanks!

[cesarliws]

Hi Stefano,

Thank you for the detailed feedback and for offering to contribute once again! Your previous contributions (#150 / #151) were excellent, and I would be glad to collaborate on these points.

Here is the feedback on both items:

1) Collections: Ordered / Sorted Dictionary & Set

I agree that IOrderedDictionary<TKey, TValue> (insertion-order, $O(1)$ lookup + iteration) is a very common requirement and a clear gap in the current Dext.Collections package.

• How to proceed: Please feel free to open a PR for IOrderedDictionary<TKey, TValue> first.
• Design Preferences: To stay consistent with Dext’s architecture, I prefer implementations that minimize heap allocations, reuse existing comparative abstractions (like our custom comparers), and expose clean, high-performance enumerators.
• Once the ordered dictionary is integrated, we can move forward with the sorted variants (ISortedDictionary<TKey, TValue> / ISortedSet<T>).

2) NextGen JSON SIMD Scanner Wiring

You are absolutely correct. The SSE4.2 scanner ScanStructural_SSE42 is currently implemented and tested but completely bypassed in the main parser loop (which still relies on scalar iteration).

• How to proceed: I would love to see a PR wiring this SIMD path into the main parse/skip loop. Since you already have local benchmark suites and real-world JSON samples, it would be extremely helpful if you could include the "before vs. after" benchmark results in the PR description to ensure we get a solid performance boost without regressions on small/scalar payloads.

Looking forward to your PRs! Let me know if you need any clarification on the collection interfaces or the parser internals before you start.