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
{{ message }}
Repository navigation
Consider performance improvements comming from PR to llparse #260
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.
changed the title [-]Cnsider performance improvements comming from PR to llparse[/-][+]Consider performance improvements comming from PR to llparse[/+]on Oct 27, 2023
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.
Used npm-link so that my llocal llparse version is used in llhttp.
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.
Activity
[-]Cnsider performance improvements comming from PR to llparse[/-][+]Consider performance improvements comming from PR to llparse[/+]lemire commentedon Nov 8, 2023
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 commentedon Nov 8, 2023
That is how I did the benchmark:
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):
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 commentedon Feb 6, 2024
Not considering this for now.
Nobody is maintaining llparse at the moment so we don't really know the infrastructure risk associated with it.