Do the steps you've listed produce much that's different than just using the sources from node?
https://gist.github.com/mhart/5107424 (and then run `nprof` in the same dir as your v8.log file) On Tuesday, 1 April 2014 14:26:51 UTC+11, Brock Pytlik wrote: > > I was able to get this working eventually though it was a pain. Here are > the steps that worked for me: > > > 1. wget http://nodejs.org/dist/v0.10.24/node-v0.10.24.tar.gz ; > #Download the src tarball for the release of node you're using from > http://nodejs.org/dist/ > 2. tar -xzvf node-v0.10.24.tar.gz > 3. git clone http://github.com/v8/v8 ; #this provides the cctest > directory that we need later on > 4. cd v8 > 5. git checkout <tag for the version of v8 you need> # I found this by > looking at node-v0.10.24/deps/v8/ChangeLog in my case it was 3.14.5 > 6. cd node-v0.10.24 > 7. ./configure && make ; #build node > 8. cd deps/v8/ > 9. ln -s <path to cloned v8>/test/ ; #this link provides the cctest > directory that the build was complaining about > 10. (cd build && ln -s ../../../tools/gyp) # link in gyp as Ben > describes above > 11. make native > 12. Run your JS program using the node you just built with the --prof > option which will generate a v8.log file > 13. OPTIONAL: edit <path to > node-v0.10.24>/deps/v8/tools/tickprocess.js to > change TickProcessor.CALL_PROFILE_CUTOFF_PCT to something other than 2.0%. > With that default, all I got in my call graph was "syscall" (which I think > was because what I profiled happened to be sleeping most of the time, but > I > could be wrong). > 14. D8_PATH=<path to node-v0.10.24 dir>/deps/v8/out/native/ <path to > node-v0.10.24 dir>/deps/v8/tools/linux-tick-processor # process your v8 log > > The result wasn't perfect, I still got a few errors like this: > >> Code move event for unknown code: 0x125542380620 >> line 24071: unknown code state: 0x110eae38fde0 > > > but only a total of 5 instead of 1000's. > > Here are the problems all this works around: > 1) no tests directory in deps/v8 in the src distribution of nodejs > 2) the lack of a link for gyp in v8's build context > > > After all that, I got a big text output with the call graph in it (among > other things). I suspect there's a way to get useful visualization from it > (something like what's in chromes developer tools), but that's a project > for another day. > > Hope this helps someone, > Brock > > > On Tuesday, April 30, 2013 8:01:19 PM UTC-7, Sam Gardner wrote: >> >> Did either of you end up figuring this out? >> >> I'm running a tiny little Arch VM and having the same issue. >> >> Sam >> >> On Thursday, April 4, 2013 1:07:29 PM UTC-5, Justin Collum wrote: >>> >>> I'm using https://github.com/bnoordhuis/node-profiler to do some >>> profiling. I've got a chunk of code that pulls in json from a file and >>> performs some logic on the objects that get loaded. There are 1000s of >>> objects and a dependency graph, so it takes a good long while. This is a >>> stress test. The code looks like: >>> >>> var profiler = require('profiler'); >>>> profiler.resume(); >>>> ce.buildDepGraph(); >>>> profiler.pause(); >>> >>> >>> OK so ce.buildDepGraph is a function that loops the objects from the >>> json and builds a dep graph. It all runs fine, but when I run v8.log >>> through the linux-tick-processor I get hundreds of lines that look >>> like: >>> >>> line 947: unknown code state: undefined >>> >>> and hundreds more like: >>> >>> Code move event for unknown code: 0x3254c6e0 >>> >>> At the end, I get this: >>> >>> >>> Statistical profiling result from v8.log, (9259 ticks, 9259 unaccounted, >>> 0 excluded). >>> >>> [Unknown]: >>> ticks total nonlib name >>> 9259 100.0% >>> >>> [Shared libraries]: >>> ticks total nonlib name >>> >>> [JavaScript]: >>> ticks total nonlib name >>> >>> [C++]: >>> ticks total nonlib name >>> >>> [GC]: >>> ticks total nonlib name >>> 0 0.0% >>> >>> [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 >>> >>> >>> Well blech, that's not even remotely useful. >>> >>> I did this profiling without node-profiler and got the same results. Do >>> I have to put the actual buildDepGraph code into this test to get it to >>> profile correctly? >>> >>> >>> -- -- 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 --- You received this message because you are subscribed to the Google Groups "nodejs" 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/d/optout.
