1/2 How good is closure optimization these days in modern JS engines? I've been thinking about it lately in regard to decorators. Ex: function wrap(d) { const {method} = d; d.method = function(...args) { // ... return method.apply(this, args); }; }
-
-
1/2 Thanks
@mathias. Is it escape analysis, though? The obj is created outside the fn and passed to it, like this: const list = []; function bar() { const d = {}; foo(d); list.push(d.f); } function foo(d) { d.f = function f() { } ; } bar(); -
2/2 `f` closes over the env record for the call to `foo`, which has a binding for `d` referring to the object. But `f` doesn't use `d` (or `eval`). I know empirically V8 optimizes this, allowing the object to be GC'd. I'm wondering if that's fairly reliable across modern engines.
End of conversation
New conversation -
-
-
This question seems to be more about GC than escape analysis. If you destructure the descriptor outside of the closure, and don't use eval inside, it should usually be possible to GC, but there are some edge cases. I wouldn't worry about this source of overhead too much, though.
-
Thanks. This comes up when adding `extras` to an element descriptor, so we can't destructure in the decorator parameter list (unless returning a new descriptor). (You'd have to have thousands and thousands of decorator calls doing this to care, of course...
) - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.