On 2013/06/06 13:39:43, danno wrote:
I assume (hope?) the extra overhead is only in the case when the profiler
is
active?
The current design is that we should always update VM state when external
callback is called this is because CPU profiler may be started and stopped
when
JS stack is non-empty. So it may occur that there is some native callback
on the
stack but the profiler never knows about it.
After discussion with Toon my intent was to try simple approach when we
always
call the interceptor no matter if profiler is active or not and add
additional
checks if that turns out slow.
In any case, I wouldn't avoid "the right thing to do" until there is
data that says it's to slow.
Now it looks like there is about 1% regression on Dromaeo DOM tests, I'll do
several more runs of the tests to make sure the results are stable and post
them
here.
I think having the internal types and moving the
machinery out of ic.cc to somewhere more appropriate (like api.cc/api.h?)
is
the
right way to go.
Actually I've already updated the patch and moved the new stuff to api.h/cc,
also reverted controversial changes to src/assembler.* No
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.
