On Mon, Apr 30, 2012 at 20:30, Chris Jimison <cjimi...@ngmoco.com> wrote:
> Hi all,
>
> I am writing a GUI based debugger for V8 and I use it a lot with
> nodejs. There is one major problem I am running into ... SlowBuffer
> is killing my debugger performance. The reason is so: when a
> breakpoint is triggered, I request the callstack for the breakpoint.
> When you request the callstack from v8 it also gives you the values of
> any local variables within the frame. If SlowBuffer happens to be one
> of those local variables it will serialize the object into a JSON
> object and send it over the port. Since the object is pretty large
> and each byte entry in slow buffer will be converted into a json named
> value pair of { name:1234, value:123}, this makes for a LOT text
> streaming out of V8 and the callstack command can take upwards to
> 30-60 seconds depending on the machine.
>
> We are currently modifying nodejs/v8 so that if object returned is a
> "SlowBuffer" then it will not return the properties of the object when
> a callstack is requested. If such a change is made would that be
> something that could be taken into the mainline of nodejs? The other
We don't generally take out-of-tree V8 patches (patches to node are,
of course, fine).
Have you investigated how Chromium handles this? I would expect them
to have hit this roadblock with their typed arrays implementation and
to (hopefully) have solved it.
> option would be to not attach the elements directly to the SlowBuffer
> object. So if SlowBuffer had a "data" member object, and all the byte
> data elements would attach to it instead, the debugger would not hit
> the performance slowdown (this is because V8 will only serialize one
> level deep into the object members).
That might be an acceptable change but only if it doesn't introduce a
performance penalty elsewhere.
