Preallocate Rust sets when extracting Python sets

[charliermarsh]

When extracting a Python set or frozenset into a Rust HashSet, we currently collect a fallible iterator. Collecting into Result loses the lower bound from the source iterator's size hint, so the set grows repeatedly even though its exact length is known. In other words, because it's fallible, Rust can't pre-size the collection.

This PR instead preallocates from the Python set's length before extracting and inserting each element. (This matches the existing pattern used for for Vec, SmallVec, and Python dictionaries into HashMap, all of which already reserve capacity from the Python collection's length.)

For a 100,000-element set, this reduces allocations from 16 to 1 and cumulative Rust allocation traffic from 2,359,388 bytes to 1,179,656 bytes.

[codspeed-hq]

Merging this PR will improve performance by 17.83%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 2 improved benchmarks
✅ 138 untouched benchmarks

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	extract_hashset	23.6 ms	19.1 ms	+23.52%
⚡	extract_hashbrown_set	19.1 ms	17 ms	+12.41%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing charliermarsh:charlie/preallocate-python-set-extraction (474fe00) with main (2e49529)}

[mejrs]

cast::<PySet> can also return a subclass of PySet, so len could potentially be overridden and buggy and oom us here.

[charliermarsh]

I could be wrong, but AFAICT, this ultimately calls PySet_Size which returns the actual size (and __len__ is never invoked). Separately, wouldn't that concern also apply to lists, which already use this behavior?

[chirizxc]

Is this a GitHub bug? I got the same message three times

[Tpt]

Thanks!

[charliermarsh]

Is this a GitHub bug? I got the same message three times.

Ugh, sorry, no -- I'm on airplane Wi-Fi and I think it re-sent a bunch of times!

[bschoenmaeckers]

cast::<PySet> can also return a subclass of PySet, so len could potentially be overridden and buggy and oom us here.

I could be wrong, but AFAICT, this ultimately calls PySet_Size which returns the actual size (and __len__ is never invoked). Separately, wouldn't that concern also apply to lists, which already use this behavior?

FYI our PyList iterator is also buggy (see #6087), so I'm inclined to allow this. Or find a solution for both list and sets.

[Tpt]

@charliermarsh Glad to merge if you think the comments have been addressed

[charliermarsh]

Just marked comments as resolved, thanks @Tpt!

[Tpt]

The CI failure is unrelated: ruff (😉) now tries to reformat code snippets in markdown and we have not pinned its version. Wil lfix tomorrow

[chirizxc]

The CI failure is unrelated: ruff (😉) now tries to reformat code snippets in markdown and we have not pinned its version. Wil lfix tomorrow

It seems worth pinning all versions of the tools in the dependency groups, including zizmor, typos, etc.