| | 1 | The profiling runcore allows users and HLL developers to profile their programs at the PIR level. Rakudo needs this desperately. |
| | 2 | |
| | 3 | * Make runloops pluggable (pluggable_runcore branch) |
| | 4 | * factor out the common runcore operations |
| | 5 | * define a struct to represent these operations |
| | 6 | * refactor existing runcores to use this struct |
| | 7 | * define a mechanism to load and register a new runcore |
| | 8 | * beware of runcore switching; probably need a better way to switch than compile-time constants |
| | 9 | * Create a new profiling dyncore |
| | 10 | * figure out the extra data and this runcore needs for profiling |
| | 11 | * open output file |
| | 12 | * store profiling information |
| | 13 | * close output file |
| | 14 | * Explore callgrind output format (NYTProf format a good second strategy) |
| | 15 | * How do you represent non-local jumps? |
| | 16 | * How do you detect non-local jumps and other CPS-style control flow changes? |
| | 17 | * How do you get current line number and source file from the active Context? |
| | 18 | * (stretch goal) How do you retrieve and record current HLL location? |
| | 19 | * How do you report different runcores (exceptions) and threads (interpreters) |
| | 20 | * Probably need to avoid PIO to avoid that overhead |
| | 21 | * Can you add timing to include what's expensive in C terms? |
| | 22 | |
| | 23 | possible problem: can callgrind represent all the ways PIR can do control flow |
| | 24 | - parrot_op_info table gets populated based on what kind of flow |
| | 25 | - function attrs in ops files will probably help too |
| | 26 | |
| | 27 | - if callgrind supports it, find what happens between ops (i.e. how much time between starting ops) |
