You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately, the benchmarks are still skewed, even after #156. Sorry I didn't realise this at the time of the PR in question.
Problem
In a given benchmark, a FakeResponse object gets re-used across iterations. At the start of each iteration, its header field (of type http.Header) is cleared. However, the clear function empties the map without reducing its capacity. Therefore, the cost (esp. in terms of heap allocations) of re-adding headers to the shared FakeResponse object in subsequent iterations is amortised.
Of course, net/http does not re-use response objects from one handler invocation to the next. Therefore, the benchmark results look better than they realistically should.
One solution
One way to fix the issue is to use a different FakeResponse object for each iteration. You don't want to account for the initialisation of each FakeResponse in the benchmark results, though. One possible approach consists in creating a collection of FakeResponses (one for each benchmark iteration) before starting the benchmark loop.
Unfortunately, the benchmarks are still skewed, even after #156. Sorry I didn't realise this at the time of the PR in question.
Problem
In a given benchmark, a
FakeResponse
object gets re-used across iterations. At the start of each iteration, its header field (of typehttp.Header
) is cleared. However, theclear
function empties the map without reducing its capacity. Therefore, the cost (esp. in terms of heap allocations) of re-adding headers to the sharedFakeResponse
object in subsequent iterations is amortised.Of course,
net/http
does not re-use response objects from one handler invocation to the next. Therefore, the benchmark results look better than they realistically should.One solution
One way to fix the issue is to use a different
FakeResponse
object for each iteration. You don't want to account for the initialisation of eachFakeResponse
in the benchmark results, though. One possible approach consists in creating a collection ofFakeResponse
s (one for each benchmark iteration) before starting the benchmark loop.New benchmark results:
The text was updated successfully, but these errors were encountered: