Paweł Murias

Currently the focus of the work on the js backend is on making nqp-js emit code that runs at a reasonable speed (so that compiling Rakudo and its setting doesn't take eons and I can iterate on it more easily). Being able to easily profile nqp-js code is very useful for that.

The js profilers I have tried didn't work out so well

• devtools had trouble with native modules as it runs in
• running directly inside chrome require webpacking
• node-inspector didn't support console.profile/console.profileEnd and it's interface locked up while profiling
• some other ones were bitrotted

Saving data using v8-profiler and loading it via chrome itself proved to work the best The run_profiled($what, $kind, $filename) method of the backend passed to the HLL::Compiler proved to be a good fit for hooking it up On the MoarVM backend $kind is either 'instrumented' or 'heap'. 'instrumented' is useful for profiling CPU usage and 'heap' for memory usage. For now I implemented only CPU profiling on the js backend so on the js backend the $kind is ignored for know. The profiling is exposed by the --profile-compile (which profiles the compilation of the code) and --profile (which profiles the code itself) options.

Example: node nqp-bootstrapped.js --profile-compile --profile-filename literals.cpuprofile t/nqp/001-literals.t

literals.cpuprofile can be then loaded using the developer tools in Chrome.

The first test file of which compilation I profiled was t/nqp/001-literals.t repeated 20 times.

It turned out removing some debugging leftovers cut the compilation roughly in half.

A bunch of other promising stuff I'll work on next also popped up.