On Sep 25, 2009, at 1:42 AM, Dag Sverre Seljebotn wrote: > 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?
Yes, that is possible as well with the same API. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
