Repository navigation
perf(deduplicator): compact Ray BTS edge buffers - #1078
vertebrateqing wants to merge 2 commits into
Conversation
|
Hi maintainers, the |
|
Thanks a lot for this contribution! I have one suggestion before merging: The PR says deduplication semantics are unchanged, but the UID range is now narrower. The old code stored UIDs as Python ints of any size. The new buffers are fixed to int64, so a UID ≥ 2^63 (for example, a uint64 or hash-derived Thanks again! |
8a8fa32 to
55c626c
Compare
|
Thanks @Qirui-jiao — addressed in The packed signed-int64 path remains the default. I added regression coverage for out-of-range values in both |
Summary
list[tuple[int, int]]edge buffers with one packed NumPy array of signed-int64 edge pairs plus destination offsets on the common path; fall back to exact object-dtype storage only for UIDs outside the signed-int64 rangePart of #1031.
Correctness
The compact representation preserves the existing routing rules:
Tests cover partition routing, one-time buffer consumption, signed and order-aligned parent arrays, connected components, out-of-range Python integer UIDs in both BTS communication phases, and cross-actor merging above
2**63.Benchmark
Targeted edge-redistribution benchmark with 64 partitions. Each input parent relation produces two routed edges. Each result is the median of three fresh processes.
Environment: macOS 15.3, Apple M4, Python 3.12.14, NumPy 2.2.6, Ray 2.58.0.
At 1M input relations, peak RSS is reduced by 91.5 MiB. The incremental RSS slope from 100K to 1M is reduced by approximately 35.2%.
Validation
pre-commit run --all-filesThe macOS build intentionally skips the optional C++ MinHash extensions, so the C++ implementation is left to Linux CI. This PR does not modify the C++ path.