Consider performance improvements comming from PR to llparse

[ngrodzitski]

Could you, please, look at the PR to llparse; nodejs/llparse#58 ?
That gives a performance boost for llhttp by scanning http-fields faster.

Since llparse seems to be quite stable (last commit in main branch was more than a year ago), thus nobody watches it carefully, and the change was made for llhttp in mind it might be the case that here is the better place to ask to consider the change in llparse.

[lemire]

How did you assess the benefits experimentally?

PR nodejs/llparse#58 bears on TableLookup. Correct? Is TableLookup used in llhttp directly or indirectly in llhttp?

Is llhttp built with support for SSSE3 or SSE4.2? I see some flag in the tests, but unless that's also used by Node.js when building for production use, then that's not very useful.

[ngrodzitski]

That is how I did the benchmark:

1. Cloned llparse and llhttp locally.
2. Did the changes in llparse.
3. Used npm-link so that my llocal llparse version is used in llhttp.
4. Rebuild llhttp and run a benchmark.

Is llhttp built with support for SSSE3 or SSE4.2? I see some flag in the tests, but unless that's also used by Node.js when building for production use, then that's not very useful.

I'm afraid I don't understand how the build of llhttp works, but to verify the changes I temporary modify llparse to provide bad code under SSE-guard macro (like adding #error "Just checking...") and then I can see that the build of llhttp fails.

Here the a way to run benchmarks (I rerun it after modification to local llparse):

cd <base_dir>/llhttp
npm link ../llparse
npm run build
npm run test
npm run bench

I guess that is not a best way to do it, but that is what my expertise in js-stuff was able to came up with.

[ShogunPanda]

Not considering this for now.
Nobody is maintaining llparse at the moment so we don't really know the infrastructure risk associated with it.