On Wed, Apr 11, 2012 at 7:25 PM, Ben Noordhuis <[email protected]> wrote:
> On Wed, Apr 11, 2012 at 15:02, Satyam Shekhar <[email protected]> > wrote: > >> The profiler is sampling based. That is, it wakes up at regular > >> intervals (ticks) and records where the instruction pointer is. If the > >> IP points to an address that cannot be resolved to a function, the > >> tick is reported as unaccounted. > > > > Why does the IP need to point to a function? Can't it just point to any > > instruction(line) in the function? > > Yes, that's implied. :-) > > Say the profiler wakes up and finds that IP == 0x1234. It looks up > that address in the program's symbol table and finds that the nearest > function is foo@0x1230. The next nearest function is bar@0x1240, > therefore the profiler knows we're in foo(). > > It's more involved than that but that's the essence of it. Hmm.. So here is another question just to pester you more. :).. Lets suppose a function in my app(iin JS) has this code: var cpp_binding = require('./cpp-binding'); function js_fn() { cpp_binding.execute(); } Now when the profiler wakes up it sees an instruction in execute fn (in cpp_binding) being executed(lets assume it consumes a lot of ticks). Now, where would these ticks counted? Will they appear in JS section -- right at the top? or will they _only_ appear in C++ section? Also, in the profiler output I sent I dont have any ticks in C++ section, however I m using bindings (node-expat, compress-buffer). Why could have that happened? > > > I think m missing something very basic here.. It d help if you could > tell me > > when would this happen? > > Unaccounted ticks? For a variety of reasons. For example, glibc > generates trampolines (executable on-stack code) that confuse the > profiler no end. > Oh ok.. is it safe to say these are due to C++ bindings or some code in V8.. > > >> None. GC is accounted for separately under the (aptly named I daresay) > >> section "GC": 36,598 ticks or 14.1% of total run time in your case. > > > > I doesn't look like it from the output. > > > > total ticks : 290423 > > unaccounted ticks : 31441 > > accounted ticks : 258982 > > shared lib ticks : 194435 > > javascript ticks : 64325 > > GC ticks : 36598 > > > > shared lib + js ticks (258760 ) ~= accounted ticks(258982) (diff of 222 > > ticks) > > I repeat: GC is accounted for *separately*. :-) > Cool. :) .. should have read what you wrote more carefully. > > > I mean when the profiler wakes up, it would look at a call trace right? > Are > > the lines logged in the JS section at the top of the stack? > > This can be misleading since the call stack might have changed due to > > setTimeouts. I want to understand how can I interpret these lines and > what > > are its caveats. > > That's how sample-based profiling works: you trade accuracy for efficiency. > Here's a GSoC project for you: augment callgrind to understand the > code V8 generates. I'll buy you a beer if you do. :-) > You know, I d actually be interested in such projects. Can you point me to some essential/good readings for V8 from where I can understand it much better. :) > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
