On Fri, Oct 7, 2011 at 11:47 PM, Nick Coghlan wrote:

On Fri, Oct 7, 2011 at 4:50 PM, Maciej Fijalkowski wrote:

...

Hi

Can we disable by default disabling the cyclic gc in timeit module? Often posts on pypy-dev or on pypy bugs contain usage of timeit module which might change the performance significantly. A good example is json benchmarks - you would rather not disable cyclic GC when running a web app, so encoding/decoding json in benchmark with the cyclic GC disabled does not make sense.

What do you think?

No, it's disabled by default for a reason (to avoid irrelevant noise in microbenchmarks), and other cases don't trump those original use cases.

People don't use it only for microbenchmarks though. Also, you can't call noise a thing that adds something every now and then I think. Er. How is disabling the GC for microbenchmarks any good by the way? Cheers, fijal

On Sat, Oct 8, 2011 at 1:47 AM, Antoine Pitrou wrote:

On Sat, 8 Oct 2011 00:13:40 +0200 Maciej Fijalkowski wrote:

...

On Fri, Oct 7, 2011 at 11:47 PM, Nick Coghlan wrote:

...

On Fri, Oct 7, 2011 at 4:50 PM, Maciej Fijalkowski wrote:

...

Hi

Can we disable by default disabling the cyclic gc in timeit module? Often posts on pypy-dev or on pypy bugs contain usage of timeit module which might change the performance significantly. A good example is json benchmarks - you would rather not disable cyclic GC when running a web app, so encoding/decoding json in benchmark with the cyclic GC disabled does not make sense.

What do you think?

No, it's disabled by default for a reason (to avoid irrelevant noise in microbenchmarks), and other cases don't trump those original use cases.

People don't use it only for microbenchmarks though. Also, you can't call noise a thing that adds something every now and then I think.

Er. How is disabling the GC for microbenchmarks any good by the way?

In CPython, looking for reference cycles is a parasitic task that interferes with what you are trying to measure. It is not critical in any way, and you can schedule it much less often if it takes too much CPU, without any really adverse consequences. timeit takes the safe way and disables it completely.

In PyPy, it doesn't seem gc.disable() should do anything, since you'd lose all automatic memory management if the GC was disabled.

it disables finalizers but this is besides the point. the point is that people use timeit module to compute absolute time it takes for CPython to do things, among other things comparing it to PyPy. While I do agree that in microbenchmarks you don't loose much by just disabling it, it does affect larger applications. So answering the question like "how much time will take json encoding in my application" should take cyclic GC time into account. Cheers, fijal

On Sat, Oct 8, 2011 at 2:18 AM, Antoine Pitrou wrote:

...

...

In CPython, looking for reference cycles is a parasitic task that interferes with what you are trying to measure. It is not critical in any way, and you can schedule it much less often if it takes too much CPU, without any really adverse consequences. timeit takes the safe way and disables it completely.

In PyPy, it doesn't seem gc.disable() should do anything, since you'd lose all automatic memory management if the GC was disabled.

it disables finalizers but this is besides the point. the point is that people use timeit module to compute absolute time it takes for CPython to do things, among other things comparing it to PyPy. While I do agree that in microbenchmarks you don't loose much by just disabling it, it does affect larger applications. So answering the question like "how much time will take json encoding in my application" should take cyclic GC time into account.

If you are only measuring json encoding of a few select pieces of data then it's a microbenchmark. If you are measuring the whole application (or a significant part of it) then I'm not sure timeit is the right tool for that.

Regards

Antoine.

When you're measuring how much time it takes to encode json, this is a microbenchmark and yet the time that timeit gives you is misleading, because it'll take different amount of time in your application. I guess my proposition would be to not disable gc by default and disable it when requested, but well, I guess I'll give up given the strong push against it. Cheers, fijal

Antoine Pitrou wrote:

...

...

In CPython, looking for reference cycles is a parasitic task that interferes with what you are trying to measure. It is not critical in any way, and you can schedule it much less often if it takes too much CPU, without any really adverse consequences. timeit takes the safe way and disables it completely.

In PyPy, it doesn't seem gc.disable() should do anything, since you'd lose all automatic memory management if the GC was disabled.

it disables finalizers but this is besides the point. the point is that people use timeit module to compute absolute time it takes for CPython to do things, among other things comparing it to PyPy. While I do agree that in microbenchmarks you don't loose much by just disabling it, it does affect larger applications. So answering the question like "how much time will take json encoding in my application" should take cyclic GC time into account.

If you are only measuring json encoding of a few select pieces of data then it's a microbenchmark. If you are measuring the whole application (or a significant part of it) then I'm not sure timeit is the right tool for that.

Perhaps timeit should grow a macro-benchmark tool too? I find myself often using timeit to time macro-benchmarks simply because it's more convenient at the interactive interpreter than the alternatives. Something like this idea perhaps? http://preshing.com/20110924/timing-your-code-using-pythons-with-statement -- Steven