On Thu, Jun 6, 2013 at 6:16 PM, Sven Panne <[email protected]> wrote:
I don't have a good solution, but always paying a penalty for a very, very
rare case (profiler is on) seems to be the wrong approach. We desperately
try to make transitioning between JS and C as cheap as possible, so
several
writes plus an additional frame/jump/return per transition is heading into
the wrong direction... :-/ It would be totally OK if this was only the
case
if the profiler is on, though.
On 2013/06/06 14:35:59, danno wrote:
I agree with Sven here. We've been working very hard at making the JS/C++
transitions really fast, I think setting the VM state in these cases is
not a
good idea.
It was exactly due to performance concerns that we don't set VM state when
CallApiFunctionAndReturn is used elsewhere. Adding this overhead for all
native
getters and setters just to support the very rare case when the sampling
profiler is active is the wrong tradeoff.
I understand that 3% is too much for such a rare case. Let me see what it
would
cost to
1) Check if profiler is active in the generated code and do either direct
call
or call into the runtime thunks based on that.
2) Always update VM state from the generated code my gut feeling is that it
could also be quite cheap enough or do you think based on your experience
that
this second option would be too expensive?
https://codereview.chromium.org/16286016/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
