Robert Bradshaw wrote: > On Sep 24, 2009, at 11:59 PM, Dag Sverre Seljebotn wrote: > > >> Robert Bradshaw wrote: >> >>> On Sep 24, 2009, at 3:37 PM, Lisandro Dalcin wrote: >>> >>> >>> >>>> I personally prefer that profile be off by default (level 0 in my >>>> proposal above), but as always, I do not bother too much about >>>> defaults provided that I can change it :-) >>>> >>>> Anyway, until you can have some more benchmarking (or in the case >>>> you >>>> do not have the time to do the benchmarking), I think you should >>>> disable the beast, just in case do not have it unintentionally >>>> enabled >>>> in final release 0.11.3... >>>> >>>> >>> Yes, lets have it disabled for 0.11.3 by default, and when I have >>> time to do some benchmarks we'll think about what to do for 0.12. If >>> it's cheap enough, it's nice to be able to not have to re-compile to >>> enable profiling (especially if it's not your code, e.g. it'd be nice >>> to have it enable for most of Sage). Maybe def methods would be a >>> nice compromise (it's much less overhead than, e.g., argument >>> unpacking). I'd like to get input from more people on this too. >>> >>> >> My personal preference: >> >> a) A directive profile which takes booleans, like the planned warning >> directive. I.e. >> >> cython.profile(all, pycall, ccall, inline, ...) >> >> The first is "all" so that you can simply pass True to turn them >> all on >> (which, when used as a function decorator, has the effect of profiling >> that one function, regardless of type, which is neat). Unfortunately >> "def" is a keyword, hence "....call". >> >> (When using an integer level I feel the learning curve is slightly >> higher and I'm able to state less clearly what I want.) >> > > Hmm, I like the idea of keywords. > > >> A priori, I'd prefer the default to be to profile "def" functions but >> not cdef/cpdef personally (except perhaps cpdef when going through the >> Python call...not sure about that), but as you say it should be >> benchmarked. >> >> b) A C macro CYTHON_PROFILE which defaults to 1 (True). Its sole >> purpose >> is to easily disable any profiling after code generation. Having >> "cython.profile(False)" everywhere would cause this macro to have >> no effect. >> > > Thanks kid of what I was thinking too. > > For 0.11.3, lets have it take a single boolean argument, defaulting > to False, and continue looking into this for a more complete (but > backwards compatible) solution for 0.12. > BTW, would it be possible through the cProfile API to enable line-by-line profiling in time, or is this as far as one gets with cProfile?
Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
