On Mon, Apr 4, 2011 at 10:25 PM, Steven D'Aprano
wrote:
> On Mon, 04 Apr 2011 20:59:52 -0700, geremy condra wrote:
>
>> On Mon, Apr 4, 2011 at 7:45 PM, Steven D'Aprano
>> wrote:
>
>>> * The disclaimers about timing code snippets that can be found in the
>>> timeit module apply. If possible, use t
On Mon, 04 Apr 2011 20:59:52 -0700, geremy condra wrote:
> On Mon, Apr 4, 2011 at 7:45 PM, Steven D'Aprano
> wrote:
>> * The disclaimers about timing code snippets that can be found in the
>> timeit module apply. If possible, use timeit rather than roll-you-own
>> timers.
>
> Huh. In looking in
In an extended case when you try and capture how a function works over a range
of inputs, you might want to not assume some relationship between input size
and time, as this mnight limit your ability to change algorithms and still have
acceptable performance.
I.e. instead of this:
input_range
On Mon, Apr 4, 2011 at 7:45 PM, Steven D'Aprano
wrote:
> I'm writing some tests to check for performance regressions (i.e. you
> change a function, and it becomes much slower) and I was hoping for some
> guidelines or hints.
>
> This is what I have come up with so far:
>
>
> * The disclaimers abou
On Mon, Apr 4, 2011 at 7:45 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> I'm writing some tests to check for performance regressions (i.e. you
> change a function, and it becomes much slower) and I was hoping for some
> guidelines or hints.
>
> This is what I have come up w
I'm writing some tests to check for performance regressions (i.e. you
change a function, and it becomes much slower) and I was hoping for some
guidelines or hints.
This is what I have come up with so far:
* The disclaimers about timing code snippets that can be found in the
timeit module appl
