Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
http: various performance improvements #10558
These commits bring 3-11% performance increase (this is on top of the performance improvements made recently in #10445, #10443, and #6533). The performance increases are greater when you start setting/adding more headers than the http benchmarks currently use (just 2 currently).
When using the 'simple' http benchmark, I had to reduce the http client benchmarker duration by half (5 seconds) and reduce the number of runs to 10 (from the default of 30) to get the results back in a reasonable amount of time, especially with the newly added benchmark parameter. This allowed me to finish benchmarking in a little over 4.5 hours, whereas before with the original duration and 30 runs it was still running after 18 hours (when it technically should have finished -- even taking into account overhead since a single run doesn't last exactly the duration specified).
With that being said, here are the results with those modified benchmarking settings:
When adding 3 custom headers in the 'setHeaderWH' case for example, you can see a greater increase:
Affected core subsystem(s)
referenced this pull request
Jan 3, 2017
CI one last time before landing: https://ci.nodejs.org/job/node-test-pull-request/5812/
EDIT: all green except for a flaky test on OSX.
I'm now marking this as semver-major because I just realized I forgot to run citgm and I just found out that there are apparently users (at least on github) that are using
So far the only instance on citgm where I ran into this is
@ChALkeR Could you find out how many other modules on npm may be affected?
I really apologize for all of this....
I've now submitted a PR that should help resolve the main use cases for end users accessing
Since IIRC we don't have an official policy on undocumented, "private" (underscore-prefixed) properties yet, it would be good to hear what others think should be the way forward on this. Some ideas:
As far as the now removed
referenced this pull request
Jan 16, 2017
That sounds like a nice enough solution. Warn in v8.x and remove in v9.x?
So to give a little detail here from Express side, the
@mscdex made some PRs and we are working to iron out some edge cases, but when Express does release a version that does not reference
My thoughts are that if 8.x is going to become the next LTS, it would be really nice if the warning / removal started in a non-LTS version based on the rate it seems people upgrade Express. From the past, even a warning will end up having a lot of fallout from confused users all over the place, so just brainstorming how can we have the best chance for the change to go out unnoticed by the vast majority of the users.