Hi Martin, this seems rather unexpected to me. Why don't you put everything you know into a V8 issue so I can take a closer look at this as soon as I have some time? http://code.google.com/p/v8/issues/
Thank you! Yang On Tue, Jun 12, 2012 at 12:29 PM, Martin <[email protected]> wrote: > Thanks for your answer, > > i was just curious about the performance impact with the debugger > because of this pdf: > http://www.daimi.au.dk/~amoeller/VM/Debugging_support_in_V8.pdf > In Page 6 theres a design criteria: No speed degrading when debugging > > anyway here's a minimal example showing my issue: > var BreakPointPerformance = function() { > } > BreakPointPerformance.prototype.breakFunc = function() { > return 0; > } > BreakPointPerformance.prototype.mathFunc = function() { > var a = Math.sqrt(Math.random()); > return a; > } > BreakPointPerformance.prototype.runLoop = function() { > console.time("loop time"); > var b = 0; > for(var i=0;i<10000000;i++) { > b+=this.mathFunc(); > } > console.timeEnd("loop time"); > } > var p = new BreakPointPerformance(); > p.runLoop(); > > On my Machine running Chrome the function takes 100ms to execute. > If i set a breakpoint at the return statement of breakFunc, which is > not executed at all, > i get around 19000ms. > I also get these 19000ms if the breakpoint is set, but disabled (if i > remember correctly this has been posted as issue already). > Why is the execution so slow even if breakFunc isn't executed? > > kind regards, > Martin > > > On 12 Jun., 08:12, Yang Guo <[email protected]> wrote: > > Hi Martin, > > > > this is a known fact. Performance critical code usually get a second > > treatment with the optimizing compiler after it has been run for a short > > while. When a breakpoint is set inside a function, it is deoptimized to > > enable breaking and debugging. This can have a big performance impact. > This > > is a conscious design decision: we do not require code that is being > > debugged to run fast. > > > > However, if you can provide a pure javascript (running on V8's dev shell, > > D8, alone) sample, I can take a look and see if there is something > unusual > > going on. > > > > Regards, > > > > Yang > > > > > > > > > > > > > > > > On Mon, Jun 11, 2012 at 11:09 PM, Martin <[email protected]> wrote: > > > Hello, > > > > > the following applies to both Chrome 19.0.1084.52 m using the > > > Developer Tools and Node.js 0.7.6 pre using node-inspector as Debug > > > Frontend. > > > I've noticed that setting a breakpoint (in frequently executed code), > > > no matter if the breakpoint is conditional or not slows down the > > > execution of javascript significally. > > > The function i'm trying to debug takes around 2 seconds to execute > > > without breakpoints. > > > If i set a breakpoint i stopped waiting for the end of execution (or > > > actually hitting the breakpoint) after 10 minutes! > > > Is this a known issue? > > > I haven't found anything related in the issue tracker. > > > > > Recently i debugged a webworker, setting a breakpoint in a function > > > which was not executed at all, but the behaviour was the same: > > > javascript execution slowed down alot. > > > > > kind regards > > > Martin > > > > > -- > > > v8-dev mailing list > > > [email protected] > > >http://groups.google.com/group/v8-dev > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
