Uh oh!
There was an error while loading. Please reload this page.
http: add doc deprecation for private props - #10941
Conversation
There was a problem hiding this comment.
Does accessing a value via a Symbol have a perf hit vs. normal property access in master?
There was a problem hiding this comment.
I don't know. I'll look into making a benchmark.
There was a problem hiding this comment.
Results with the following benchmark (is it worth adding to the repo?): targos@d50c790
# master
$ ./node benchmark/es/object-property-bench.js
es/object-property-bench.js millions=1000 method="property": 1,137.5161172810194
es/object-property-bench.js millions=1000 method="string": 1,133.78613592118
es/object-property-bench.js millions=1000 method="variable": 1,137.9577172760735
es/object-property-bench.js millions=1000 method="symbol": 1,133.090467628974
# v7.4.0
$ node benchmark/es/object-property-bench.js
es/object-property-bench.js millions=1000 method="property": 1,136.7741112855451
es/object-property-bench.js millions=1000 method="string": 1,136.7865674716409
es/object-property-bench.js millions=1000 method="variable": 1,135.1437992275612
es/object-property-bench.js millions=1000 method="symbol": 1,136.4064052769731
# v4.7.1
$ node benchmark/es/object-property-bench.js
es/object-property-bench.js millions=1000 method="property": 1,135.4850535131566
es/object-property-bench.js millions=1000 method="string": 1,134.4381133016345
es/object-property-bench.js millions=1000 method="variable": 78.62998231306928
es/object-property-bench.js millions=1000 method="symbol": 81.82481813228071There was a problem hiding this comment.
Ok so it might be worth sticking to properties for now.
As far as adding the benchmark, it could be useful. Although I'd probably put it in misc/ instead of es/ since it doesn't primarily deal with es6+ alternatives (which es/ seems to contain).
There was a problem hiding this comment.
it might be worth sticking to properties for now
I don't think so. The numbers are very close and on multiple runs, the order varies a lot. It would be worth only for v4.x
There was a problem hiding this comment.
I've been testing this like crazy lately and from everything I have seen there is essentially zero perf impact from using symbols.
jasnell
commented
Jan 23, 2017
+1 to using a symbol instead. |
fd32784 to
16bd79cComparemscdex
commented
Jan 25, 2017
@jasnell@targos Switched to symbol. CI: https://ci.nodejs.org/job/node-test-pull-request/6054/ |
thefourtheye
commented
Jan 28, 2017
Isn't this a major change? |
mscdex
commented
Feb 19, 2017
This PR needs at least one more approval from a @nodejs/ctc member in order for it to land (again, after #10805 lands). |
ce2aab4 to
953b97eComparemscdex
commented
Feb 20, 2017
Updated PR to use one of the new http API methods and to reuse |
rvagg
commented
Feb 21, 2017
do we have any ecosystem usage metrics for this? that's my only concern before agreeing. |
@rvagg I don't know, all I can do is run in CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/586/
|
rvagg
commented
Feb 21, 2017
@ChALkeR are you still the one to find this data? |
dougwilson
commented
Feb 22, 2017
P.S. I know I shouldn't have done this, but had some code that was functionclearHeaders(res){res._headers={}res._headerNames={}}Obviously needs to change. Right now works on Node.js 8, but this landing will break even that without any warning. Should probably keep that working with a warning if the getters would keep working, right? |
@dougwilson Yeah I'm not sure what the best solution to that would be as far as the behavior of the setter, since we'd probably have to just copy the values out of the object instead of just using the same object reference (because the internal representation changed). Should we blindly copy values in the Thoughts on this @nodejs/collaborators ? |
mscdex
commented
Mar 6, 2017
I'll land this on Tuesday if there are no more objections before then. Here's another CI: https://ci.nodejs.org/job/node-test-pull-request/6720/ |
mikeal
commented
Mar 6, 2017
It looks like a lot of reverse compatibility work has been done here, can we get a redux of what won't work anymore after this change? |
evanlucas
commented
Mar 7, 2017
I'm still a bit concerned with deprecating res._headers. Although it isn't documented as a public api, it is used in so many places. Is it really justifiable to break the ecosystem like this? |
mscdex
commented
Mar 7, 2017
@mikeal As far as I know there shouldn't really be any difference with the getters/setters in place. @evanlucas I don't understand the concern, there is no runtime deprecation anymore. It's a documentation deprecation. Also there are now other public http APIs that cover all of the use cases I've seen thus far for accessing the private properties. |
8126753 to
0cc96d1Compareevanlucas
commented
Mar 8, 2017
@mscdex even with a docs only deprecation, that still more than likely means we are going to remove it eventually. I'm just not sure whether it is justified. I do seem to be in the minority on this one though so ¯\(ツ)/¯ |
@evanlucas Well yes, that is the plan for deprecations. I don't see how it's a problem considering it's only a docs deprecation for v8.0.0 and there are public methods that cover the current use cases for these private properties (these methods should be backported to v4.x and v6.x). IMHO there will be plenty of time for people to convert their code to use these new methods before the old, private properties become a runtime deprecation and eventually removed. This PR also fixes a backwards compatibility issue that currently exists in master, so that is why I've been wanting to get this landed sooner than later. |
0cc96d1 to
9be372fComparemscdex
commented
Mar 9, 2017
A day late, but last CI before landing: https://ci.nodejs.org/job/node-test-pull-request/6759/ and last CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/633/ |
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
9be372f to
8243ca0ComparePR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This is one proposed solution to the current backwards compatibility issue (see #10558) in master with end users who directly access
outgoingMessage._headers/outgoingMessage._headerNames.This PR will be simplified some once #10805 is landed (which should land before this PR). Specifically, the
._headersgetter can simply just returnthis.getHeaders()./cc @nodejs/collaborators
CI: https://ci.nodejs.org/job/node-test-pull-request/6054/
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)