On Sat, Oct 8, 2011 at 2:18 AM, Antoine Pitrou <solip...@pitrou.net> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com