Improve HTTPHeaders description performance

[supersonicbyte]

Motivation:

As outlined in this issue by @weissi, the current performance of calling description on HTTPHeaders is undermined by the dynamism of Array.

Modifications:

The proposed solution replaces the implementation of description to iterate over the items and print them out manually. This provides a faster solution since we bypass the cost of calling into description of an Array.

Result:

A more performant implementation of HTTPHeaders description.

[Lukasa]

I think we need a benchmark here to get an idea of whether this is actually faster.

[supersonicbyte]

Sure, I'm happy to add benchmarks to confirm this. @weissi Would you mind sharing with me how did you generate the images from the original issue? I tried to reach out to you on X/Twitter. Thanks.

[weissi]

Sure, I'm happy to add benchmarks to confirm this. @weissi Would you mind sharing with me how did you generate the images from the original issue? I tried to reach out to you on X/Twitter. Thanks.

Oh sorry, I'm mostly on Bluesky these days.

If you're on a Mac, the easiest thing is probably to write a quick harness that does

@_optimise(none) @inline(never)
func blackhole(_ string: String) { precondition(string.utf8.count >= 0) }

@inline(never)
func GO() {
    let httpHeaders = ["some": "example", "headers": "small", "and": "looooo...ng", ...]
    for _ in 0..<100_000 {
        let str = "\(httpHeaders)"
        precondition(str.utf8.count > 100)
   }
}

GO()

then compile that in release mode and run it with time ./my-harness.

To see the Flame Graphs on Mac, using Instruments is easiest.

[weissi]

And ideally, you'd add the benchmark to the NIOPerformanceTester target too.

[supersonicbyte]

Thank you @weissi!

I did some tests and here is what I found.

Consider the following harness:

@_optimize(none) @inline(never)
func go() {
    let headers = Array(repeating: ("Test", "Test"), count: 100)

    for _ in 1...1_000 {
        let str = headers.description
        precondition(str.utf8.count > 100)
    }
}

go()

After compiling it with :

swiftc -O -o array_description array_description.swift

and running time the output is:

./array_description  0.22s user 0.00s system 98% cpu 0.232 total

Now, let's consider the harness with which replaces the call to description with the proposed optimization:

@_optimize(none) @inline(never)
func go() {
    let headers = Array(repeating: ("Test", "Test"), count: 100)

    for _ in 0...1_000 {
        let str = headers.lazy.map {
                "\($0.0): \($0.1)"
            }
            .joined(separator: "; ")
        precondition(str.utf8.count > 100)
    }
}

go()

We can copmpile it with the same flags and run time. The output is:

./array_optimized_description  0.02s user 0.00s system 93% cpu 0.028 total

We can see that we have a roughly 8x increase in speed.

I also added a benchmark to the NIOPerfomanceTester target too.

Last, but not least, the flame graphs 🔥.

[weissi]

[...]

Super cool, thank you!!

[Lukasa]

Shiny, this is fantastic. Thanks so much @supersonicbyte! ✨ I'll kick off CI and see what it thinks.

[Lukasa]

Ok, so somewhat unsurprisingly we've improved our allocation count numbers, which causes the integration tests to fail (so that we can revise the thresholds downwards). If you're on macOS, the solution for updating these is to open the CI jobs one-by-one, copy the output, and then run pbpaste | ./dev/alloc-limits-from-test-output --json > IntegrationTests/tests_04_performance/Thresholds/<matching-threshold>.json. On other platforms the command will be roughly similar except that you'll need to handle the pasting a bit differently.

[supersonicbyte]

Ok, so somewhat unsurprisingly we've improved our allocation count numbers, which causes the integration tests to fail (so that we can revise the thresholds downwards). If you're on macOS, the solution for updating these is to open the CI jobs one-by-one, copy the output, and then run pbpaste | ./dev/alloc-limits-from-test-output --json > IntegrationTests/tests_04_performance/Thresholds/<matching-threshold>.json. On other platforms the command will be roughly similar except that you'll need to handle the pasting a bit differently.

Hey @Lukasa, I don't believe that is the case actually. I have run the suggested command but it didn't generate any diff from current main. Then I dig in deeper and found out actually that the reason of the failing is test_07_headers_work.sh. It expected the old output of the HTTPHeaders description. I updated the test. Can you kick off the CI again, please? I think we should be good now.

[Lukasa]

Oh nice, good catch, thanks!