HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/plain; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 07:03:32 GMT Content-length: 3786 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) 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. == architecty todo == - work through RFC tickets - prepare for Lorito brain dump on dec 9 - put architecture team to work - work through (and blog about): - GC - Namespaces - imcc - pcc - exceptions and exception handling - lexicals - NCI - get back to work on opmap-aware packfile implementation (unoptimized, using PMC-based versions of the structs) == misc todo == - Take a shot at implementing one-pass lazy PMC class initialization. - http://irclog.perlgeek.de/parrot/2010-06-20#i_2460692 - 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 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. - Profile/optimize the profiling runloop code. == profiling testing todo: == - Make docs/dev/profiling.pod helpful to a (hypothetical) annoyed and scared newbie. - Figure out what to test. (see [wiki:TestingProfiling]) - 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 (should parrot get proper threading) - 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 [http://irclog.perlgeek.de/parrot/2010-08-03#i_2659752 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.