Allow passing an offset and count to FnvHash64.GenerateHash()#8444
Allow passing an offset and count to FnvHash64.GenerateHash()#8444andrewlock wants to merge 1 commit intoandrew/client-side-stats/update-processing-pipelinefrom
FnvHash64.GenerateHash()#8444Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e94c3c9c6e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| var max = offset + count; | ||
| for (var i = offset; i < max; i++) |
There was a problem hiding this comment.
Validate offset/count before hashing region
The new GenerateHash(byte[], int offset, int count, ...) path never validates range arguments before iterating, and max = offset + count can lead to silent wrong results for invalid inputs (for example, a negative count makes the loop a no-op and returns initialHash instead of failing). This regression only occurs when callers provide out-of-range values, but in that case it masks slicing bugs and can produce incorrect hashes without any exception; add explicit checks for offset >= 0, count >= 0, and offset + count <= data.Length before hashing.
Useful? React with 👍 / 👎.
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8444) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-time benchmarks measure the whole time it takes to execute a program, and are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are highlighted in **red**. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). Duration chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (71ms) : 68, 74
master - mean (72ms) : 69, 74
section Bailout
This PR (8444) - mean (75ms) : 73, 77
master - mean (76ms) : 75, 78
section CallTarget+Inlining+NGEN
This PR (8444) - mean (1,067ms) : 1026, 1107
master - mean (1,066ms) : 1023, 1110
FakeDbCommand (.NET Core 3.1)gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (111ms) : 108, 115
master - mean (111ms) : 108, 115
section Bailout
This PR (8444) - mean (112ms) : 110, 114
master - mean (113ms) : 110, 116
section CallTarget+Inlining+NGEN
This PR (8444) - mean (780ms) : 753, 807
master - mean (783ms) : 763, 803
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (99ms) : 95, 103
master - mean (99ms) : 95, 103
section Bailout
This PR (8444) - mean (100ms) : 96, 103
master - mean (99ms) : 97, 102
section CallTarget+Inlining+NGEN
This PR (8444) - mean (932ms) : 893, 972
master - mean (931ms) : 903, 960
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (98ms) : 95, 101
master - mean (98ms) : 95, 101
section Bailout
This PR (8444) - mean (99ms) : 96, 101
master - mean (98ms) : 96, 100
section CallTarget+Inlining+NGEN
This PR (8444) - mean (816ms) : 782, 850
master - mean (811ms) : 778, 844
HttpMessageHandler (.NET Framework 4.8)gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (198ms) : 193, 203
master - mean (191ms) : 188, 195
section Bailout
This PR (8444) - mean (201ms) : 199, 204
master - mean (195ms) : 193, 196
section CallTarget+Inlining+NGEN
This PR (8444) - mean (1,174ms) : 1121, 1228
master - mean (1,141ms) : 1097, 1185
HttpMessageHandler (.NET Core 3.1)gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (285ms) : 279, 290
master - mean (273ms) : 269, 277
section Bailout
This PR (8444) - mean (285ms) : 281, 290
master - mean (274ms) : 271, 277
section CallTarget+Inlining+NGEN
This PR (8444) - mean (953ms) : 916, 990
master - mean (925ms) : 905, 944
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (279ms) : 272, 286
master - mean (268ms) : 265, 272
section Bailout
This PR (8444) - mean (279ms) : 275, 284
master - mean (268ms) : 265, 270
section CallTarget+Inlining+NGEN
This PR (8444) - mean (1,153ms) : 1116, 1189
master - mean (1,136ms) : 1093, 1179
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8444) - mean (277ms) : 272, 283
master - mean (267ms) : 262, 271
section Bailout
This PR (8444) - mean (276ms) : 273, 279
master - mean (266ms) : 263, 270
section CallTarget+Inlining+NGEN
This PR (8444) - mean (1,036ms) : 985, 1087
master - mean (1,018ms) : 979, 1058
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BenchmarksBenchmark execution time: 2026-04-16 09:05:49 Comparing candidate commit 25dabec in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 26 metrics, 0 unstable metrics, 87 known flaky benchmarks.
|
e94c3c9 to
9b41576
Compare
2a9f4b3 to
2106339
Compare
9b41576 to
25dabec
Compare
2106339 to
1783517
Compare
Summary of changes
Allow passing an offset and count to
FnvHash64.GenerateHash()Reason for change
Let's us hash values stored in a
byte[]that comes from an array pool, instead of requiring hashing the wholebyte[]. Allows for various optimizations in places.Implementation details
int offset, int countvaluesbyte[]to use the overloadTest coverage
Added unit tests to cover the new behaviour
Other details
Part of a stack:
charhelpers likeIsAsciiHexDigit#8417IpAddressObfuscationUtilfor use with client-side-stats #8418ContainsSpanIdtoSpanCollection#8435