On Jul 15, 2009, at 8:48 PM, Kurt Smith wrote: >> Absolutely. After all, profiling is not more than collecting >> information >> like "I'm here, time is XYZ". We emit tons of error handling code >> that >> contains line information, so this would just be one line more for >> each >> line of Cython source, and likely similar to the code generated >> for the >> ref-nanny. >> >> I'd also certainly go for emit_marker() here (which simply needs >> to get >> fixed wherever it's not accurate enough to mark each line). We >> need to make >> sure that this only emits code inside of C function bodies, though. >> > > Alright, so maybe my transform idea is going the way of the dodo. > That's fine, especially if it's too much for this task.
A transform would be hard because it has no concept of "once per line" and one would probably like to add the profiling information at the very top and bottom of an function (e.g. before arguments are parsed, though after acquiring the GIL). >> It would be good to look into the Python extensions to gdb first, >> I'd say. >> Something like that might work well enough already. After all, >> when you >> debug, you *must* see the C code, so that's different from profiling. For many debugging situations, viewing the C code is no more necessary than viewing the Python bytecodes for CPython. Of course, if you're doing C-level stuff, sometimes you need to, and for debugging Cython itself you have to look at the source. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
