-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deps: introduce experimental llhttp
HTTP parser
#24059
Conversation
cc @nodejs/http |
cc @nodejs/collaborators |
It’s not clear which part are written in TypeScript. I did some experiments recently, and I found out that a major bottleneck in our http implementation are C++/JS transitions. May I ask why this was not sent as a major contribution to http_parser? Would you be ok in transfering this to the foundation? |
I’m sorry, I must have included the link to the “source” of the project:
https://github.com/indutny/llhttp .
Although the API is similar, the projects are very different internally.
I’d be happy to transfer it to foundation, though.
As for the reason for the change - it is maintenance rather than
performance (the performance is about 2x times better, though!)
Additionally, in the future we could potentially make it generate fully
compatible JS output instead of C to remove the call overhead.
…On Sat, Nov 3, 2018 at 11:36 Matteo Collina ***@***.***> wrote:
It’s not clear which part are written in TypeScript. I did some
experiments recently, and I found out that a major bottleneck in our http
implementation are C++/JS transitions.
May I ask why this was not sent as a major contribution to http_parser?
Would you be ok in transfering this to the foundation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#24059 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAOjw9Pq00eEwn-LiiMEF7wFR-58xeSSks5urbfngaJpZM4YM2cb>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm so glad this is finally happening 🎉
@indutny I was wondering when will/if you'll PR this ;) |
|
Windows compilation errors:
|
There seems to be some Windows incompatibilities.
|
@targos hopefully fixed now. |
This is no longer relevant. llparse generates very fast C code, and bitcode is no longer required for the builds. |
I like the direction here and I'm definitely +1... but, I'd prefer to be a bit conservative on the approach with this... rather than removing and replacing the existing |
@jasnell that would require a lot of |
While I'd generally prefer not to have to go that route, yes, I think it would be best... if only because of (a) how critical this particular bit of the code is for Node.js and (b) how performance and security sensitive this particular bit of code has always been. |
deps/http_parser/http_parser.c
Outdated
, s_res_H | ||
, s_res_HT | ||
, s_res_HTT | ||
, s_res_HTTP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Goodbye old friend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ry you're stalking me
Alright, pushed the @jasnell PTAL |
http_parser
with llhttp
llhttp
HTTP parser
New CI: https://ci.nodejs.org/job/node-test-pull-request/18322/ (testing only http_parser mode) |
IIUC |
Notable changes: * deps: * A new experimental HTTP parser (`llhttp`) is now supported. #24059 * timers: * Fixed an issue that could cause setTimeout to stop working as expected. #24322 * Windows * A crashing process will now show the names of stack frames if the node.pdb file is available. #23822 * Continued effort to improve the installer's new stage that installs native build tools. #23987, #24348 * child_process: * On Windows the `windowsHide` option default was restored to `false`. This means `detached` child processes and GUI apps will once again start in a new window. #24034 * Added new collaborators: * [oyyd](https://github.com/oyyd) - Ouyang Yadong. #24300 * [psmarshall](https://github.com/psmarshall) - Peter Marshall. #24170 * [shisama](https://github.com/shisama) - Masashi Hirano. #24136
Notable changes: * deps: * A new experimental HTTP parser (`llhttp`) is now supported. #24059 * timers: * Fixed an issue that could cause setTimeout to stop working as expected. #24322 * Windows * A crashing process will now show the names of stack frames if the node.pdb file is available. #23822 * Continued effort to improve the installer's new stage that installs native build tools. #23987, #24348 * child_process: * On Windows the `windowsHide` option default was restored to `false`. This means `detached` child processes and GUI apps will once again start in a new window. #24034 * Added new collaborators: * [oyyd](https://github.com/oyyd) - Ouyang Yadong. #24300 * [psmarshall](https://github.com/psmarshall) - Peter Marshall. #24170 * [shisama](https://github.com/shisama) - Masashi Hirano. #24136 PR-URL: #24350
@indutny How does one opt-in into using it? Or it has to be consumed on a library level, e. g. from Express.js side? |
@kibertoad it is currently a build-time flag, so you have to compile Node by passing the |
love it!! Can I use it by default in the upcoming Node.js 12? |
PR in progress to make this a runtime flag: #24739 |
Should this be dont-land-on-v10.x and dont-land-on-v11.x, BTW? |
+1 |
@joyeecheung +1 |
Too late for 11.x. This is already in v11. 2.0 |
@targos oops, I meant 8.x, somehow my fingers were not controlled by my brain.. |
why do node decide to adopt this then? |
@tuananh this section answers it: https://github.com/indutny/llhttp#why |
@indutny by adopting llhttp, isn't it gonna be adding more maintenance responsibility as we need to maintain both llparse and llhttp? |
Good point. Still both libraries are way more maintainable than http_parser in its current form. |
llhttp is modern, written in human-readable TypeScript, verifiable, and
is very easy to maintain.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes