Message149213
Pending work yet: (documented to avoid forgeting it)
- Performance hit because trying to determine the source line in each function call. To be solved with ¿tolerable? memory overhead. Would be acceptable to sacrifice x2/x4 time the pyc filesize (in memory) in order to avoid any runtime performance hit?. That is, a million bytecodes (not a bad program size) could need 2/4 MB. I think it is a good investment if DTRACE becomes performance-transparent.
- Build procedure is flaky. I am asking DTrace developers.
- DTRACE/GCC offset/bitmasks doesn't coincide. Instead of wiring offsets manually, they should be detected at compile time, automatically.
- Add new probes. Suggestions?. What do you want to instrumentalize?. I am thinking about the GIL, module import
- Try the code with "clang" instead of GCC.
- Address pending review comments done by Martin v. Löwis.
- Use PEP 3155.
- Trace C function calls/returns, not only Python ones. The problem here is to know the name of the function, because we can call it in a million different ways. Memorizing the last attribute lookuped is not enough. It seems necessary to memorize some extra metadata at C import. |
|
Date |
User |
Action |
Args |
2011-12-11 06:03:13 | jcea | set | recipients:
+ jcea, loewis, rhettinger, ronaldoussoren, belopolsky, pitrou, wsanchez, movement, techtonik, serverhorror, glyph, laca, twleung, jbaker, robert.kern, sirg3, danchr, dhduvall, dmalcolm, mjw, Garen, neologix, lasizoillo, fche, hazmat, jmcp, scox |
2011-12-11 06:03:13 | jcea | set | messageid: <1323583393.76.0.0461171903834.issue13405@psf.upfronthosting.co.za> |
2011-12-11 06:03:13 | jcea | link | issue13405 messages |
2011-12-11 06:03:12 | jcea | create | |
|