If it helps, the full trace is here: https://gist.github.com/1531674 The function I'm spending 25-45% of my time in is Arbiter.applyImpulse. Source is here: https://github.com/josephg/Chipmunk-js/blob/master/lib/cpArbiter.js#L349-406
On Thu, Dec 29, 2011 at 2:18 PM, Joseph Gentle <[email protected]> wrote: > Wow, thats awesome information. That would explain why the function in > question is slow, and why inlining a couple of the function calls it makes > decreases overall speed. > > How do I read the trace I get back? I'm getting this: > > **** DEOPT: Arbiter.applyImpulse at bailout #49, address 0x0, frame size 264 > [deoptimizing: begin 0x1b70ac6a67f1 Arbiter.applyImpulse @49] > translating Arbiter.applyImpulse => node=432, height=216 > 0x7fff6f711630: [top + 248] <- 0x3ebe7f33eb9 ; [esp + 296] 0x3ebe7f33eb9 > <JS Object> > 0x7fff6f711628: [top + 240] <- 0x2457afa6b4ad ; caller's pc > 0x7fff6f711620: [top + 232] <- 0x7fff6f7116c0 ; caller's fp > .... > > I assume address 0x0 means something the function is doing is hitting a null > object. Does bailout #49 mean anything? The function is (later) repeatedly > optimized and deoptimized again with bailout #8. How do I track these down? > > -J > > > On Monday, 26 December 2011 23:56:31 UTC+11, Vyacheslav Egorov wrote: >> >> This is a multiplication stub that is usually called from non-optimized >> code (or optimized code that could not be appropriately specialized). >> Non-optimizing compiler does not try to infer appropriate representation for >> local variable so floating point numbers always get boxed. >> >> If this stub is high on the profile then it usually means that optimizing >> compiler either failed to optimize hot function which does a lot of >> multiplications or it failed to infer an optimal representation for some >> reason. >> >> Bottom up profile should show which functions invoke the stub. Then you >> should inspect --trace-opt --trace-bailout --trace-deopt output to figure >> out what optimizer does with those function. >> >> -- >> Vyacheslav Egorov >> >> On Mon, Dec 26, 2011 at 7:00 AM, Joseph Gentle <[email protected]> wrote: >>> >>> What does it mean when I see BinaryOpStub_MUL_Alloc_HeapNumbers in my >>> profile? Does that mean the compiler is putting local number variables on >>> the heap? Why would it do that? >>> >>> -J >>> >>> -- >>> v8-users mailing list >>> [email protected] >>> http://groups.google.com/group/v8-users >> >> > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
