Thanks, I try Object.setPrototypeOf method.
On Friday, August 5, 2016 at 5:56:09 PM UTC+8, Andreas Rossberg wrote:
>
> Seconding what Jakob said. As a rule of thumb, you should assume that
> proxies are 10x slower than real objects, and that that is not going to
> change radically. If some cases
V8 doesn't (consistently) handle oom situations but expects the allocator
to crash the process if it can't fulfill a request.
Paul Baker schrieb am Mi., 3. Aug. 2016, 11:55:
> It appears that V8 allocates JavaScript objects on a manually-managed
> heap, memory for which is ultimately obtained fr
Seconding what Jakob said. As a rule of thumb, you should assume that
proxies are 10x slower than real objects, and that that is not going to
change radically. If some cases are faster than that then you are merely
lucky.
On 5 August 2016 at 11:27, Jakob Kummerow wrote:
> I wouldn't say it's due
I wouldn't say it's due to current implementation details. The
specification for most Proxy operations just demands very complicated (and
therefore slow) internal workflows. In performance-sensitive code, it's
probably better to avoid using Proxies -- usually the same functionality
can also be achi
Thank you very much! These are very helpful for me.
On Friday, August 5, 2016 at 4:21:18 PM UTC+8, cbr...@chromium.org wrote:
>
> Proxies and the Reflect functions are implemented in C++ which means that
> currently there are two things that will cause a slowdown over the simple
> delegator obje
Proxies and the Reflect functions are implemented in C++ which means that
currently there are two things that will cause a slowdown over the simple
delegator object that installs getters and setters:
1. the optimizing compiler cannot inline or otherwise improve calls to
proxies
2. calls to proxi
