deps: introduce experimental `llhttp` HTTP parser by indutny · Pull Request #24059 · nodejs/node

indutny · 2018-11-03T15:27:54Z

llhttp is modern, written in human-readable TypeScript, verifiable, and
is very easy to maintain.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
commit message follows commit guidelines

nodejs-github-bot · 2018-11-03T15:27:55Z

@indutny build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/1469/pipeline

indutny · 2018-11-03T15:28:15Z

cc @nodejs/http

indutny · 2018-11-03T15:28:22Z

cc @nodejs/collaborators

mcollina · 2018-11-03T15:35:16Z

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?

indutny · 2018-11-03T15:50:11Z

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> .

joyeecheung · 2018-11-03T16:23:47Z

ci: https://ci.nodejs.org/job/node-test-pull-request/18315/

devsnek

I'm so glad this is finally happening 🎉

mscdex · 2018-11-03T16:38:01Z

Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/257/

refack · 2018-11-03T16:57:05Z

@indutny I was wondering when will/if you'll PR this ;)
Last time you commented about this, you said it's slower then http_parser? Did you find how to optimized that?

refack · 2018-11-03T17:05:59Z

Only trunk and upcoming 6.0.1 version of clang are supported at the moment is this a limitation of llparse, since the generated code seems to be compiling on GCC4.9?

refack · 2018-11-03T17:08:19Z

Windows compilation errors:

12:25:31 src\http_parser.c(5840): note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast

12:25:31 src\http_parser.c(827): warning C4065: switch statement contains 'default' but no 'case' labels [c:\workspace\node-compile-windows\deps\http_parser\http_parser.vcxproj]

12:25:31 src\http_parser.c(6036): error C2664: 'int (http_parser_t *,const char *,const char *)': cannot convert argument 2 from 'void *' to 'const char *' [c:\workspace\node-compile-windows\deps\http_parser\http_parser.vcxproj]
12:25:31 src\http_parser.c(6036): note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast

targos · 2018-11-03T17:11:14Z

There seems to be some Windows incompatibilities.
Errors all look like that:

12:25:31 src\api.c(48): error C2440: '=': cannot convert from 'void *' to 'http_parser_settings_t *' [c:\workspace\node-compile-windows\deps\http_parser\http_parser.vcxproj]
12:25:31 src\api.c(48): note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast

indutny · 2018-11-03T17:35:55Z

@targos hopefully fixed now.

indutny · 2018-11-03T17:36:33Z

@refack

Only trunk and upcoming 6.0.1 version of clang are supported at the moment is this a limitation of llparse, since the generated code seems to be compiling on GCC4.9?

This is no longer relevant. llparse generates very fast C code, and bitcode is no longer required for the builds.

jasnell · 2018-11-03T17:45:01Z

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 http_parser immediately, perhaps the new parser can be landed as experimental alongside and enabled with a command-line flag? e.g. --experimental-http-parser? At least through 11.x ... then, we can switch it in as the default with an --legacy-http-parser option in 12.x to use the old one, with an eye towards removing it in 13.x.

indutny · 2018-11-03T17:49:11Z

@jasnell that would require a lot of #ifdefs. Are you okay with that?

jasnell · 2018-11-03T17:57:46Z

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.

ry · 2018-11-03T18:51:51Z

Goodbye old friend

@ry you're stalking me

indutny · 2018-11-03T23:56:07Z

Alright, pushed the --experimental-http-parser configure flag. It appears to be building/running just fine, and the tests pass for both modes. What I'm not sure about is the shared_* options...

@jasnell PTAL

indutny · 2018-11-04T00:26:01Z

New CI: https://ci.nodejs.org/job/node-test-pull-request/18322/ (testing only http_parser mode)

refack · 2018-11-04T00:53:04Z

What I'm not sure about is the shared_* options...

IIUC node_shared_http_parser is for systems that provide their own packdged http_parser.so (Debian for example).
I believe llhttp.so is very rare to find, so I'd say --experimental-http-parser overrides --shared_http_parser. You could put an "if (both): exit configure.py" guard.

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

kibertoad · 2018-11-17T12:14:29Z

@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?

targos · 2018-11-17T13:06:27Z

@kibertoad it is currently a build-time flag, so you have to compile Node by passing the --experimental-http-parser flag to ./configure.
When enabled, it replaces the HTTP parser entirely.

zuohuadong · 2018-11-21T14:13:21Z

love it!!

Can I use it by default in the upcoming Node.js 12?

joyeecheung · 2018-12-05T15:25:52Z

PR in progress to make this a runtime flag: #24739

joyeecheung · 2018-12-05T15:28:45Z

Should this be dont-land-on-v10.x and dont-land-on-v11.x, BTW?

mcollina · 2018-12-05T17:39:24Z

+1

indutny · 2018-12-05T17:42:44Z

@joyeecheung +1

targos · 2018-12-05T17:52:28Z

Too late for 11.x. This is already in v11. 2.0

joyeecheung · 2018-12-05T18:15:39Z

@targos oops, I meant 8.x, somehow my fingers were not controlled by my brain..

tuananh · 2018-12-07T02:17:14Z

IMHO ~0 net effect on performance.

why do node decide to adopt this then?

indutny · 2018-12-07T02:28:02Z

@tuananh this section answers it: https://github.com/indutny/llhttp#why

tuananh · 2018-12-07T02:38:36Z

@indutny by adopting llhttp, isn't it gonna be adding more maintenance responsibility as we need to maintain both llparse and llhttp?

indutny · 2018-12-07T02:42:36Z

Good point. Still both libraries are way more maintainable than http_parser in its current form.

addaleax · 2018-12-07T12:04:49Z

@tuananh See also the discussion in #24730 – adopting llhttp as the default parser in Node 12 may give us the freedom to abandon http_parser at some point in its lifetime, if we decide that maintaining http_parser is unreasonable.

nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Nov 3, 2018

indutny requested a review from bnoordhuis November 3, 2018 15:28

devsnek approved these changes Nov 3, 2018
View reviewed changes

refack added the http_parser Issues and PRs related to the HTTP Parser dependency or the http_parser binding. label Nov 3, 2018

refack reviewed Nov 3, 2018
View reviewed changes

Comment threaddeps/http_parser/http_parser.gyp Outdated

refack added the notable-change PRs with changes that should be highlighted in changelogs. label Nov 3, 2018

refack added the build Issues and PRs related to build files or the CI. label Nov 3, 2018

refack reviewed Nov 3, 2018
View reviewed changes

Comment threaddeps/http_parser/http_parser.gyp Outdated
Comment threaddeps/http_parser/http_parser.gyp Outdated

ry reviewed Nov 3, 2018
View reviewed changes

indutny changed the title ~~deps: replace http_parser with llhttp~~deps: introduce experimental llhttp HTTP parserNov 4, 2018

refack reviewed Nov 4, 2018
View reviewed changes

Comment threaddeps/llhttp/llhttp.gyp Outdated

mcollina added dont-land-on-v6.x labels Dec 5, 2018

Uh oh!

Uh oh!

Conversation

indutny commented Nov 3, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

nodejs-github-bot commented Nov 3, 2018

Uh oh!

indutny commented Nov 3, 2018

Uh oh!

indutny commented Nov 3, 2018

Uh oh!

mcollina commented Nov 3, 2018

Uh oh!

indutny commented Nov 3, 2018 via email

Uh oh!

joyeecheung commented Nov 3, 2018

Uh oh!

devsnek left a comment

Choose a reason for hiding this comment

Uh oh!

mscdex commented Nov 3, 2018

Uh oh!

refack commented Nov 3, 2018

Uh oh!

Uh oh!

refack commented Nov 3, 2018

Uh oh!

refack commented Nov 3, 2018

Uh oh!

targos commented Nov 3, 2018

Uh oh!

indutny commented Nov 3, 2018

Uh oh!

indutny commented Nov 3, 2018

Uh oh!

jasnell commented Nov 3, 2018

Uh oh!

indutny commented Nov 3, 2018

Uh oh!

jasnell commented Nov 3, 2018

Uh oh!

Uh oh!

Uh oh!

ryNov 3, 2018

Choose a reason for hiding this comment

Uh oh!

indutnyNov 3, 2018

Choose a reason for hiding this comment

Uh oh!

indutny commented Nov 3, 2018

Uh oh!

indutny commented Nov 4, 2018

Uh oh!

Uh oh!

refack commented Nov 4, 2018

Uh oh!

kibertoad commented Nov 17, 2018

Uh oh!

targos commented Nov 17, 2018

Uh oh!

zuohuadong commented Nov 21, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joyeecheung commented Dec 5, 2018

Uh oh!

joyeecheung commented Dec 5, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcollina commented Dec 5, 2018

Uh oh!

indutny commented Dec 5, 2018

Uh oh!

targos commented Dec 5, 2018

Uh oh!

joyeecheung commented Dec 5, 2018

Uh oh!

tuananh commented Dec 7, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

indutny commented Nov 3, 2018•
edited
Loading

zuohuadong commented Nov 21, 2018•
edited
Loading

joyeecheung commented Dec 5, 2018•
edited
Loading

tuananh commented Dec 7, 2018•
edited
Loading