search

tc39 / proposal-function-implementation-hiding

JavaScript language proposal: function implementation hiding
https://ci.tc39.es/preview/tc39/ecma262/pull/1739
MIT License
98 stars 7 forks source link

Appendix statement untrue for some engines #30

Closed erights closed 4 years ago

erights commented 4 years ago

"with JavaScript engine implementers revealed the basic premise behind the memory-saving mechanism was flawed. It wouldn't, in fact, save memory!"

This is not true of XS. Thus, this sentence should make clear that the premise applies to some engines but not to others.

Attn @phoddie

hax commented 4 years ago

I introduced this proposal to some senior programmers and many have the first impression that "hide implementation" could save memory because no function source need to preserved, and "sensitive" could further increase performance because eliminating some stack info and the "sensitive" functions could be inlined...

So I'm very worry about abusing of these directives...

michaelficarra commented 4 years ago

@hax See the appendix for more about how the directive will not affect memory usage for mainstream engines. Regarding the stack info, engines are already free to perform TCE due to PTCs. So even through a non-standard stack inspection API, you still can't rely on presence in a stack trace or absence of inlining.

Whether the community is stupid enough to sprinkle these directives all over due to expectant performance gains despite the advice given to them by people who should know better is another question.

mstade commented 4 years ago

Whether the community is stupid enough to sprinkle these directives all over due to expectant performance gains despite the advice given to them by people who should know better is another question.

What a remarkable statement to make.

hax commented 4 years ago

See the appendix for more about how the directive will not affect memory usage for mainstream engines.

@michaelficarra Of coz I've read it before I introduced this proposal. What I mean is:

Whether the community is stupid enough to sprinkle these directives all over due to expectant performance gains despite the advice given to them by people who should know better is another question.

I feel we can't easily say abusing "is a another question". At least this not match many other similar cases I've read in many other proposals.

michaelficarra commented 4 years ago

@hax Yeah I'm not saying that we should ignore the potential for its abuse. I'm just saying there's not much we can do to predict misuse/abuse of features we add. We just need to consider what the consequences will be. Will they be bad for the whole ecosystem or just the perpetrator? Is it something that could be solved through outreach?