> I doubt that the compiler can optimize the memcpy calls away. We
profiled a
> release build of d8, and more than 10% of the total runtime are spend in
memcpy.
I think I found one of the problems: While MemoryRead and MemoryWrite will
call
memcpy since they work on arbitrary length, MemoryRead8/16/32/64 and
MemoryWrite32/64 will not as expected. Our mistake is that when we
implemented
the LoadStoreHelper in the simulator instead of using the fixed size
MemoryRead/Write we used the generic version with a variable for size.
rewriting
the helper to use the specialised versions (and maybe add MemoryWrite8/16)
should give you some performance back without using reinterpret_cast.
Could you try and see how much do you get this way?
https://codereview.chromium.org/169223004/
--
--
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.
