On Mon, Apr 8, 2013 at 11:40 PM, phantomriver <[email protected]>wrote:
> > *Could someone help me understand what is going on in this tick-processor > output?* > (I'm not focusing on the the UI aspect of this code so I grayed the > entries related to DOM.)* > * > > 1. I see that in the [JavaScript] section, we have > calculateWide()appearing as optimized; yet, it appears again on the bottom as > un-optimized. > One of my questions is, is this caused by a "bailout" of the v8 > optimizing compiler? > > Not necessarily. Every function runs as unoptimized code first. After a (very short) while, the optimizing compiler decides to kick in. In this example, the unoptimized version doesn't even show up in the profile by itself, just in the bottom up profile: it was on the stack as a caller of something else that received a profiler tick. So it looks like everything is just fine. > > 1. Secondly, I see calculateNarrow() appearing* twice* in the [J > avaScript] section once as slow and once as optimized. Does this > indicate that the code used a lot of time and was optimized, or rather that > optimization failed and we had to bail out? > > As I said above, this is normal. Both versions of this function only received one single tick, so there's too little data to say anything for sure, but OTOH since it's just a single tick it's nothing to worry about. > > 1. Is it a performance problem indicator if ntdll.dll uses almost 90% > of the ticks? > > Depends on what you're doing. For some operations, we call system libraries. This profile looks like it's been generated with Chrome on some website; I'm not sure but I think when V8 is just sitting around and waiting for more stuff to do (timers or events to fire, pages to get loaded, ...), so time is being spent in some waiting function, that might show up as "ntdll.dll" in the profile. > > 1. Finally, is there some way I can determine whether the Stub: and > Builtin: lines are caused by the calculateWide() or calculateNarrow() > procedures, or something else? > > The bottom up profile shows that, but as it says in the output, it doesn't display callers occupying less than 2% of the overall time (to avoid uselessly noisy output). Since again all of these only saw a single tick each, I'd recommend not to worry about them :-) > > 1. > > > > > >> Statistical profiling result from null, (995 ticks, 1 unaccounted, 0 >> excluded). >> >> [Unknown]: >> ticks total nonlib name >> 1 0.1% >> [Shared libraries]: >> ticks total nonlib name >> 893 89.7% 0.0% C:\Windows\SysWOW64\ntdll.dll >> 75 7.5% 0.0% C:\Users\DevUser\AppData\Local\Google\Chrome >> SxS\Application\28.0.1467.0\chrome.dll >> 5 0.5% 0.0% C:\Windows\syswow64\GDI32.dll >> 4 0.4% 0.0% C:\Windows\syswow64\USER32.dll >> 4 0.4% 0.0% C:\Windows\system32\WINMM.dll >> 2 0.2% 0.0% C:\Windows\syswow64\kernel32.dll >> 1 0.1% 0.0% C:\Windows\syswow64\KERNELBASE.dll >> [JavaScript]: >> ticks total nonlib name >> *6 0.6% 54.5% LazyCompile: *calculateWide >> http://localhost:8888/app.js:13217* >> 1 0.1% 9.1% Stub: KeyedLoadElementStub >> 1 0.1% 9.1% Stub: CEntryStub >> 1 0.1% 9.1% LazyCompile: ~calculateNarrow >> http://localhost:8888/app.js:13158 >> 1 0.1% 9.1% LazyCompile: *calculateNarrow >> http://localhost:8888/app.js:13158 >> 1 0.1% 9.1% Builtin: A builtin from the snapshot >> [C++]: >> ticks total nonlib name >> [GC]: >> ticks total nonlib name >> 3 0.3% >> [Bottom up (heavy) profile]: >> Note: percentage shows a share of a particular caller in the total >> amount of its parent calls. >> Callers occupying less than 2.0% are not shown. >> ticks parent name >> 893 89.7% C:\Windows\SysWOW64\ntdll.dll >> 75 7.5% C:\Users\DevUser\AppData\Local\Google\Chrome >> SxS\Application\28.0.1467.0\chrome.dll >> 2 2.7% LazyCompile: ~getImageSrc >> http://localhost:8888/app.js:823 >> 1 50.0% LazyCompile: ~createImageElement >> http://localhost:8888/app.js:6459 >> 1 100.0% LazyCompile: ~createElements >> http://localhost:8888/app.js:547 >> 1 100.0% LazyCompile: ~getUiElements >> http://localhost:8888/app.js:2479 >> 1 100.0% LazyCompile: ~loadElements >> http://localhost:8888/app.js:1187 >> 1 50.0% LazyCompile: ~buildApplicationFrame >> http://localhost:8888/app.js:1411 >> 1 100.0% LazyCompile: ~loadElements >> http://localhost:8888/app.js:1187 >> 2 2.7% LazyCompile: ~createElements >> http://localhost:8888/app.js:547 >> 2 100.0% LazyCompile: ~getUiElements >> http://localhost:8888/app.js:2479 >> 2 100.0% LazyCompile: ~loadElements >> http://localhost:8888/app.js:1187 >> * 2 2.7% LazyCompile: ~calculateWide >> http://localhost:8888/app.js:13217* >> 2 100.0% LazyCompile: ~marshalCalculations >> http://localhost:8888/app.js:13365 >> 1 50.0% LazyCompile: ~prepareData >> http://localhost:8888/app.js:5614 >> 1 100.0% LazyCompile: ~initMain >> http://localhost:8888/app.js:2165 >> 1 100.0% LazyCompile: ~onLoaded >> http://localhost:8888/app.js:1339 >> 1 50.0% LazyCompile: ~prepareData >> http://localhost:8888/app.js:4985 >> 1 100.0% LazyCompile: ~initMain >> http://localhost:8888/app.js:2165 >> >> 1 100.0% LazyCompile: ~onLoaded >> http://localhost:8888/app.js:1339 >> >> -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
