On 2015/08/28 09:48:40, fedor.indutny wrote:
Hello again,
Thanks for the thorough review! Will fix everything mentioned as soon as
possible, hopefully today.
We see two bottlenecks in node.js: one happens during buffer allocation,
one
during GC. Both add together and make things slightly slower than they
could
potentially be. Here is a benchmark that we are using to figure out exact
numbers: https://gist.github.com/trevnorris/efe36274b0d0a23a78f5 .
This patch cuts down performance overhead by 15% according to Trevor
Norris
(it
was a bit bigger on my machine, so it probably fluctuates and depends on
the
speed of memory allocation too).
Ugh, a microbenchmark. Did you also see it in real-world applications?
The problem I see in general with this benchmark is that we allocate a lot
of
memory without actually using it. Upon allocating a buffer this large you
should
also use it (read/write), effectively dominating the bookkeeping overhead.
Is there a reason why there is no API to have ArrayBuffer contents
allocated
inline in the object itself? Not that we could solely use this API, but in
many
cases it could potentially give us better performance, because of absence
of
bookkeeping.
Usually objects contain room for some elements themselves and are backed by
some
other store for larger sizes (and are thus tracked by the frontend object).
As
far as I see the array buffer in question is already a backing store, so it
requires extra handling to be used stand alone. The reason why some store
are
treated differently is often because of how memory can move between the
embedder
and V8.
-Michael
https://codereview.chromium.org/1316873004/
--
--
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/d/optout.
