[xperiandri]

Proposed Changes

Builds on #31. Fixes IndexedList.ofList and ofSeq of an F# list, which built the tree in O(n²), and makes the walking functions and choose of IndexedList (and IIndexedList.choose) faster for reference types and lighter for long lists. No public signature changes.

This is the lower pull request of a stack: #45 (ofArray from a span, and the pooled temporary arrays) is on top of it. The measurements are in the comments of #45, because they were made for the whole stack: the first gives the method and which numbers to trust, the second ofList and the Walk loops, the third choose, the fifth the other collections (1, 2, 3, 5). Every number in the commit messages and below comes from them.

Commit	What it does	Measured effect
4d98858 fix: ofList and ofSeq of an F# list copy the list before they build the tree	ImmutableList.CreateRange indexes an F# list, whose indexer is O(i)	100 000 elements: 6.6 s -> 1.6 ms (integers), 6.4 s -> 1.9 ms (strings)
849d6b6 perf: IndexedList walks a list of reference types through the interface	an internal module Walk picks the enumerator with typeof<'T>.IsValueType, because the struct enumerator is slow in the code shared by reference types	strings: iter 0.6, fold 0.7, tryPick 0.6, mapi and scan 0.7 to 0.9 of the time; integers unchanged. mapFold keeps its loop (the Walk loop took 1.1 to 1.4 times as long)
d381e3f perf: choose collects the elements in an array that is rented from the pool for a long list	Buffers.ChosenBuffer: a new array below 1024 elements, ArrayPool above, capped at 1 048 576 elements (a longer result moves into a list)	allocation 15 to 21 % (integers) and 25 to 35 % (strings) lower and no collections of the second generation from the buffer; at 100 000 and a million elements the time is equal for integers (0.90 to 1.03) and 0.65 to 0.89 for strings

Ratios are the time relative to the code before; below 1 is faster. A difference inside the noise (about ±10 %, and ±34 % for calls of 100 elements) is not claimed.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• Build and tests pass locally (the whole test project: 16 710 test runs on net8.0 and net10.0, 16 skipped as before)
• I have added tests that prove my fix is effective or that my feature works: long lists for ofList, ofSeq and choose (100, 50 and 1 % chosen); the walking functions on strings; the buffer around the length where the pool starts, its spill and the clearing of the rented array
• I have added necessary documentation: the remarks of ofList and ofSeq in the signature file, and the doc comments of the helpers (they carry the measured numbers, as the comments of Collectors do)

Further comments

Why the pool, and not something simpler. The elements of choose are not counted in advance, and the tree is built once from them. Four buffers were measured for it, with capacity, with a span, with an exact array and with a rented one, and chunks joined as subtrees and the builder as the extremes (third comment of #45). The rented array wins on allocation (the tree needs 46 875 KB for a million elements; the ResizeArray allocated 17 % more for integers and 35 % more for strings, in arrays that go to the large object heap and cause collections of the second generation) and is not slower beyond the noise; chunks give a tree whose indexer is slower, an array of the length of the source allocates 7 to 11 times as much as the old code when 1 % is chosen, and the builder is 1.2 to 3.3 times slower.

What is not here. ofArray and replicate, and the pool for the temporary arrays of init, sub, rev, mapi and the others, are in #45. The other collections were measured for the same interface walk (fifth comment of #45); only SortedSet and SortedMap gain, in #46 and #47. exists2, forall2 and compareWith of IndexedList still walk two struct enumerators in step. unfold is unchanged.

🤖 Generated with Claude Code