[Question]: The TechEmpower Benchmark is misleading, but can we make it even faster?

[Mark Reed]

Actions I've taken before I'm here

• I've thoroughly read the documentations about this problem but still have no answer.
• I've searched the Github Issues/Discussions but didn't find any similar problems that have been solved.
• I've searched the internet for this problem but didn't find anything helpful.

Questions with details

I suggest removing or updating the techempower benchmark as it is misleading since it doesn't do any parsing and tricked me into thinking go was far more performant than it is. All of the top benchmarks are cheating, but the rest at least check the path.

However. Can we make gnet even faster in this benchmark? The current parser is this:

`bytes.Index(data, hc.delimiter);`

Is it possible to use AVX2 instructions in Go? If so is it likely to be faster? If someone can point me to the best way to do this I can try it out and see if we can scan to the \r\n\r\n faster.

Code snippets (optional)

No response

[Andy Pan]

There's been a tanglesome story about the HTTP implementation of gnet evolving in TechEmpower. The current and simplest implementation was a reluctant action after the intended implementation failed to work on the TechEmpower environment while it's working perfectly on my Mac and Linux server and achieving the same performance as that simplest implementation. I couldn't figure out the inconsistent behaviors with the same code between the TechEmpower environment and my local environment, and it's also unlikely for me to diagnose the issue in the environment of TechEmpower. Furthermore, I was getting tired of making any more wild guesses about the problem without being able to verify the speculation, so I just threw a simple implementation on it and got the hell out of that.

If you can seek out the root cause why the intended implementation wouldn't work in the TechEmpower environment and fix it, please be my guest and open a PR to update the code of gnet in the FrameworkBenchmarks. That doesn't matter to me because I had benchmarked the intended implementation and the simple implementation locally: they performed at the same level.