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

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by redsandro on 23 May 2013 at 12:52

[GoogleCodeExporter]

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?

Original comment by peter.ry...@gmail.com on 23 May 2013 at 1:00

[GoogleCodeExporter]

> 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. :)

Original comment by redsandro on 23 May 2013 at 9:41

Attachments:

• slowdebug.js

[GoogleCodeExporter]

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?

Original comment by redsandro on 23 May 2013 at 10:40