diff --git a/dev/bench/data.js b/dev/bench/data.js index 9824826164..aaa18de2f7 100644 --- a/dev/bench/data.js +++ b/dev/bench/data.js @@ -1,5 +1,5 @@ window.BENCHMARK_DATA = { - "lastUpdate": 1728671422936, + "lastUpdate": 1729006133540, "repoUrl": "https://github.com/hyperium/hyper", "entries": { "pipeline": [ @@ -8762,6 +8762,36 @@ window.BENCHMARK_DATA = { "unit": "ns/iter" } ] + }, + { + "commit": { + "author": { + "email": "sean@seanmonstar.com", + "name": "Sean McArthur", + "username": "seanmonstar" + }, + "committer": { + "email": "sean@seanmonstar.com", + "name": "Sean McArthur", + "username": "seanmonstar" + }, + "distinct": true, + "id": "3900a2381b96a7e7f608a5e031b3e90ddcdfcd74", + "message": "perf(http1): improve parsing of sequentially partial messages\n\nIf request headers are received in incremental partial chunks, hyper\nwould restart parsing each time. This is because the HTTP/1 parser is\nstateless, since the most common case is a full message and stateless\nparses faster.\n\nHowever, if continuing to receive more partial chunks of the request,\neach subsequent full parse is slower and slower. Since partial parses is\nless common, we can store a little bit of state to improve performance\nin general.\n\nNow, if a partial request is received, hyper will check for the end of\nthe message quickly, and if not found, simply save the length to allow\nthe next partial chunk to start its search from there. Only once the end\nis found will a fill parse happen.\n\nReported-by: Datong Sun ", + "timestamp": "2024-10-15T08:28:03-07:00", + "tree_id": "c71c7e4fb8dfcac629682e8a830453d4141dea4c", + "url": "https://github.com/hyperium/hyper/commit/3900a2381b96a7e7f608a5e031b3e90ddcdfcd74" + }, + "date": 1729006131306, + "tool": "cargo", + "benches": [ + { + "name": "hello_world_16", + "value": 48263, + "range": "± 9399.11", + "unit": "ns/iter" + } + ] } ], "end_to_end": [