Re: [JS-internals] Performance impact of Debugger

2013-10-14 Thread Jason Orendorff
On 10/14/13 12:03 PM, Jim Blandy wrote: > [...]there's probably no need to separate bytecode instructions that > have no visible side effects from their successors. Filed bug 926528, " JSD2: Reduce the number of positions where a breakpoint can be placed". https://bugzilla.mozilla.org/show_bug.cgi?

Re: [JS-internals] Performance impact of Debugger

2013-10-14 Thread Jim Blandy
On 10/14/2013 05:17 AM, Jan de Mooij wrote: Especially if Esprima has many short-running function calls, the 5x instead of 3x slowdown is not unexpected I think. It should be easy to temporarily disable the prologue/epilogue calls and see how much faster that makes us (search for debugMode_ in

Re: [JS-internals] Performance impact of Debugger

2013-10-14 Thread Jan de Mooij
On Sat, Oct 12, 2013 at 2:57 PM, Jason Orendorff wrote: > What's up with #2? Do the debug epilogues really cost that much? Or are > we accidentally inhibiting Baseline somehow? When debug mode is enabled we do the following: (1) Call DebugPrologue and DebugEpilogue (jit/VMFunctions.cpp) when ent

Re: [JS-internals] A precise memory reporting test

2013-10-14 Thread Jeff Walden
On 10/14/2013 03:34 AM, Benjamin Peterson wrote: > I wonder if JS shell builds should (at least optionally) link with > mozalloc and jemalloc to better simulate browser conditions in our > everyday correctness and performance testing. Really, all of mozalloc/mozglue/etc. should move into mfbt, and