This page is a personal todo list for me, cotto. Others are welcome to take on any tasks mentioned here, but the primary purpose for this page is to keep track of what I intend to do. Because of that, I haven't spend much effort on breaking tasks down into bite-size chunks or made much of a concrete plan. If you are interested in helping but don't know where to start, catch me on #parrot and I'll put you to work.

todo (important, in decreasing order):

• some way to measure how much time is being spent in each nqp-rx subroutine or method? I know we had stuff using kcachegrind at one point, but I could never get it to work much with pge or nqp-rx because it seemed to have difficulty with tailcalls.
• make --stagestats for PCT::HLLCompiler less noisy
• Take a shot at implementing one-pass lazy PMC class initialization.
•  http://irclog.perlgeek.de/parrot/2010-06-20#i_2460692
• Make the Deprecation page not suck
  • troll through svn logs and fill in what needs to be done
• add stuff from  http://irclog.perlgeek.de/parrot/2010-05-28#i_2378589 to LoritoRoadmap
• Add a test for #1652 to t/profiling/profiling.t
• Annotations are slow. Make it possible to avoid a Schlemiel the Painter algorithm by getting annotations from bytecode iteratively.
  •  http://irclog.perlgeek.de/parrot/2009-12-12#i_1828456
  • Get to know the PackFile code.
    • Read through the bytecode pdd (13) and make it match the current implementation.
    • Focus on annotations, but it wouldn't be a bad thing to raise the PackFile bus number.
    • docs/parrotbyte.pod duplicates some of pdd13. Merge parrotbyte.pod into the pdd. It's hard enough to keep one document up-to-date.
    • It'd also be nice to speed up Parrot_Sub_get_line_from_pc since it currently eats about 15% of the processing time *after* caching its results. Knowing PackFiles might help.
• test profiling output (pprof format)
• test pprof to callgrind conversion and callgrind-style output
• Create an efficient binary output format with optional compression, similar to NYTProf.
  • Alternately, consider moving the Callgrind output code into the profiling runcore and using the pprof output only for testing.
  • Look into spitting out NYTProf-compatible output too.
• Optimize the profiling runloop code. Major refactors should wait until some tests are in place.

todo (would be nice):

• Fix CLI argument parsing so that options can be passed to the profiling runcore.
  • It'd also be nice if parrot were smart enough to treat -Rp or -Rprof to the same as -Rprofiling
    • This is a trivial change to compilers/imcc/main.c
• Switch to a Configure.pl-based approach for finding the appropriate timing functions.

profiling testing todo:

• Make docs/dev/profiling.pod helpful to a (hypothetical) annoyed and scared newbie.
• Figure out what to test. (see TestingProfiling)
• Write some fake tests to figure out what the profiling testing interface should look like.
• pprof2cg (split into a module, test individual components, multiple output formats (when implemented))
  • The Callgrind output code may end up in C since nqp is way too slow and even the Perl 5 version isn't very fast. This would make testing more interesting, though I'd still have a way to produce either the pprof or the callgrind formatted output.
  • There's now no reason that multiple output formats can't coexist apart from the extra testing burden.
• specific test cases
  • test all output types (currently none and pprof, possibly cg and nytprof if I get ambitious)
  • hello world
  • profiling a pbc without line information (if possible)
  • proper namespace support
  • threads
• make profiler useful to HLLs (nqp especially, pge would be helpful too)
  • time spent per sub/method would be very helpful to pmichaud
  • deal gracefully with tailcalls
• optimize pprof2cg, see  this and the ensuing discussion

Questions:

• What are "basic blocks" in Callgrind's format? Callgrind's docs aren't at all helpful here. UTSL applies.
  • A basic block is a straight line piece of code without any branches or branch targets. It's the smallest individual unit of code to which you can apply a compiler optimization.