#87 Debugging when working with large objects can increase execution time 100 fold

[Anonymous]

Originally created by: redsandro

Chromium JavaScript Remote Debugger Version: 0.3.8.201210040400
Eclipse version: 3.8.0
Google Chrome/V8 Embedder + version:
[For WebKit (WIP) protocol] Backend version:
OS + version: Ubuntu 12.10

I am hoping that someone recognizes this and might point me to a duplicate issue, because try and try but I cannot recreate this problem in a testcase.

I have a large script that combines different (private) sources into a multidimensional array with objects as values. This array is flattened, but has a lot of references. All references are cloned, so they are no longer references, resulting in a very big object.

This all executes in under one second. But add a breakpoint anywhere, and execution time (before the code actually arrives on the breakpoint) suddenly rises to 60 seconds.

I tried to recreate this in different ways using random object generators, but I cannot seem to recreate this problem. Breakpoint or not, execution time is identical.

What is the expected result?
Code pauses on first breakpoint without a massive delay.

What happens instead?
Massive delay of 60+ seconds.

It looks like setting a breakpoint causes the V8 debugger to recreate the object on a Z80 emulator.

[Anonymous]

Originally posted by: peter.ry...@gmail.com

V8 breakpoint subsystem is far from being fully optimized, some parts are written quite simplistic and with trivial data structures. The breakpoint code is likely to degrade in performance on big number of breakpoints or a very long functions. I guess the performance issue never actually came up.

Do I understand right, that you CAN reproduce it 100%, you simply cannot share the example?

[Anonymous]

Originally posted by: redsandro

> Do I understand right, that you CAN reproduce it 100%, you simply cannot share the example?

This is true. It uses 3rd party parts and sources I cannot share. Admittedly it is huge so any combination of factors might weigh into it, but once I remove the 'flatten' parts, the delay-on-breakpoint goes away.

I tried to emulate the behavior but I don't see why it does not work. Attached is a javascript file. PLEASE NOTE that it does NOT SHOW THE BEHAVIOR. It merely complements my poor story telling skills by showing what I mean.

Interesting detail, the big object manipulation part /seems/ to cause this behavior, but adding a breakpoint /before/ the actual function call yields the same problem.

Sorry about the caps. :)

[Anonymous]

Originally posted by: redsandro

I see (one thread of) the CPU working for ~63 seconds when the debugger in Eclipse is listening. It would be interesting if there's a way to find out what it's working on. Maybe I am saying something stupid, but is there some way to output what the debugger is working on? If I can output a line number to a log file every second, then 62 seconds should be stuck on something that passes through easily otherwise. Or doesn't it work that way?