tisonkun commented on PR #311: URL: https://github.com/apache/datasketches-rust/pull/311#issuecomment-6435567308
Fresh performance results for `a9492473520511c292612ed94a029ef2bff71eac`. `insert` now uses unconditional bit updates for every hash count; `contains_and_insert` keeps conditional writes. This follows the merged #306 and supersedes its single-hash dispatch policy. ### Method - Apple M4 Max, macOS ARM64, Rust 1.99.1, release defaults. The measurement thread requests user-initiated QoS; the host is not isolated and CPU affinity is not pinned. - Revisions: pre-#306 baseline `675e3e123fda6da19657d345038252b16adc2ebb`, merged #306 `db1bca8231f444b2fca0992a0fa68c4d874a953b`, and this follow-up `a9492473520511c292612ed94a029ef2bff71eac`. - All three revisions were clean-built sequentially at the same absolute Cargo package paths using `cargo +1.99.1 build --release`, then saved as separate executables. SHA-256 checks before and after the run confirmed that the measured binaries did not change. Exploratory assembly-emitting builds and mixed-build timings are excluded from these results. - Each workload has a fixed count shared by all three executables, calibrated to about 300 ms on the baseline. Seven rounds rotate execution order, with warm-up before timing. Times are actual whole-batch medians, not scaled request latencies. - Ordinary filters have 191,744 bits. Fresh cases construct/drop one filter per 20,000 items inside timing. Repeated cases use prepopulated fixtures; saturated cases use a fully set 64-bit filter. The 32-byte inputs encode a sequential item number in the first eight bytes and zero-fill the rest. Fixture/input preparation is outside timing. - Targeted membership and serialization checks matched across all three revisions. ### Results Changes in the last column are medians of the paired `current / merged #306 - 1` time changes: negative is faster. They can differ slightly from ratios of the displayed median times. Counts are inserted items for fresh workloads and calls for other workloads. | Workload | Hashes | Items/calls per sample | Pre-#306 baseline | Merged #306 | This PR | Time change vs merged #306 | | --- | ---: | ---: | ---: | ---: | ---: | ---: | | Fresh `u64` insertion | 1 | 26,880,000 | 301.60 ms | 291.52 ms | 273.86 ms | -5.72% | | Fresh `u64` insertion | 7 | 7,000,000 | 293.67 ms | 116.46 ms | 119.56 ms | +1.16% | | Fresh `u64` insertion | 12 | 4,680,000 | 303.76 ms | 99.39 ms | 100.39 ms | +0.68% | | Fresh 32-byte insertion | 1 | 22,620,000 | 299.44 ms | 352.64 ms | 268.61 ms | -23.57% | | Fresh 32-byte insertion | 7 | 6,160,000 | 302.52 ms | 153.69 ms | 135.84 ms | -11.54% | | Fresh 32-byte insertion | 12 | 4,020,000 | 301.34 ms | 134.84 ms | 119.12 ms | -11.75% | | Repeated `insert` | 1 | 31,480,000 | 299.47 ms | 287.53 ms | 325.00 ms | +12.75% | | Repeated `insert` | 7 | 19,640,000 | 295.00 ms | 325.22 ms | 326.85 ms | +1.17% | | Repeated `insert` | 12 | 14,000,000 | 301.37 ms | 303.41 ms | 311.06 ms | +2.17% | | Saturated-filter `insert` | 1 | 32,100,000 | 301.78 ms | 289.69 ms | 327.13 ms | +13.64% | | Saturated-filter `insert` | 7 | 19,800,000 | 298.33 ms | 321.29 ms | 326.80 ms | +1.05% | | Saturated-filter `insert` | 12 | 14,520,000 | 298.96 ms | 307.12 ms | 312.05 ms | +1.50% | | Repeated `contains_and_insert` | 1 | 28,080,000 | 301.37 ms | 289.65 ms | 291.25 ms | +0.39% | | Repeated `contains_and_insert` | 7 | 17,920,000 | 288.28 ms | 235.04 ms | 237.72 ms | +2.83% | | Repeated `contains_and_insert` | 12 | 13,520,000 | 300.23 ms | 245.73 ms | 255.97 ms | +4.20% | | Membership hits | 7 | 19,020,000 | 299.01 ms | 294.93 ms | 296.00 ms | -0.03% | | Membership misses | 7 | 10,820,000 | 297.90 ms | 290.20 ms | 293.01 ms | +0.97% | ### Tradeoffs - Against merged #306, fresh 32-byte insertion takes about 23.5% less time with one hash and about 11.5-11.8% less time with 7/12 hashes. Fresh `u64` insertion takes about 5.8% less time with one hash; the multi-hash `u64` cases are within about 1.2%. - Removing the conditional single-hash path costs about 12.8% more time for repeated single-hash insertion and 13.6% more time for saturated single-hash insertion. These are real costs of the simpler policy, not correctness failures. - Against the pre-#306 baseline, fresh multi-hash insertion is approximately 2.2-3.0x faster in this matrix. However, repeated/saturated `insert` workloads still regress: single-hash cases take about 8.5% more time, and the 7-hash cases about 9-11% more time. This remains a workload-specific optimization, not a universal net win or a pass for an all-workloads-within-5% rule. - `contains_and_insert` is the combined query-and-record API, retaining conditional writes suitable for repeated items. Using it follows the caller's need for prior membership; repeated plain `insert` is still legitimate usage, so its regressions should not be dismissed as choosing the wrong API. - Source-level simplification can also affect inlining and code layout. The measured deltas are whole-program effects of these builds, not an isolated cycle cost for one comparison or branch. The results are local ARM64 measurements and do not establish the outcome on the earlier Xeon host. ### Meaning of `num_hashes` and validation `num_hashes` is the conventional Bloom-filter parameter `k`: the number of hash-derived bit-position probes per item. This implementation computes two XXHash64 base hashes and derives `k` positions from them; it does not invoke `k` distinct hashing algorithms, and derived positions may repeat. The follow-up clarifies this in the getter, builder, and module documentation without changing API names or the serialized format. `cargo x check`, `cargo x test` (777 passed), and full `cargo x lint` passed. Lint ran on a clean source copy containing the same changes because generated `target/package` manifests in the original checkout fail Taplo formatting. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
