This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients eitan.adler, methane, pitrou, serhiy.storchaka, vstinner, yselivanov
Date 2018-05-31.14:50:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1527778239.14.0.682650639539.issue33597@psf.upfronthosting.co.za>
In-reply-to
Content
Here is a micro-benchmark of GC overhead:

* before:

$ ./python -m timeit -s "import gc, doctest, ftplib, asyncio, email, http.client, pydoc, pdb, fractions, decimal, difflib, textwrap, statistics, shutil, shelve, lzma, concurrent.futures, telnetlib, smtpd, tkinter.tix, trace, distutils, pkgutil, tabnanny, pickletools, dis, argparse" "gc.collect()"
100 loops, best of 5: 2.41 msec per loop

* after:

$ ./python -m timeit -s "import gc, doctest, ftplib, asyncio, email, http.client, pydoc, pdb, fractions, decimal, difflib, textwrap, statistics, shutil, shelve, lzma, concurrent.futures, telnetlib, smtpd, tkinter.tix, trace, distutils, pkgutil, tabnanny, pickletools, dis, argparse" "gc.collect()"
100 loops, best of 5: 2.52 msec per loop

So it's a 4% slowdown, but GC runs themselves are a minor fraction of usual programs' runtime, so I'm not sure that matters.  Though it would be better to test on an actual GC-heavy application.
History
Date User Action Args
2018-05-31 14:50:39pitrousetrecipients: + pitrou, vstinner, methane, serhiy.storchaka, yselivanov, eitan.adler
2018-05-31 14:50:39pitrousetmessageid: <1527778239.14.0.682650639539.issue33597@psf.upfronthosting.co.za>
2018-05-31 14:50:39pitroulinkissue33597 messages
2018-05-31 14:50:39pitroucreate