[Python-Dev] C API for gc.enable() and gc.disable() (original) (raw)
Adam Olsen rhamph at gmail.com
Fri Jun 20 19:54:15 CEST 2008
- Previous message: [Python-Dev] C API for gc.enable() and gc.disable()
- Next message: [Python-Dev] C API for gc.enable() and gc.disable()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Jun 20, 2008 at 9:44 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
2008/6/20 Kevin Jacobs <jacobs at bioinformed.com> <bioinformed at gmail.com>:
On Fri, Jun 20, 2008 at 10:25 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
Kevin Jacobs <jacobs bioinformed.com> <bioinformed gmail.com> writes: > > +1 on a C API for enabling and disabling GC. I have several instances > where I create a large number of objects non-cyclic objects where I see huge GC overhead (30+ seconds with gc enabled, 0.15 seconds when disabled). Could you try to post a stripped-down, self-contained example of such behaviour? $ python -m timeit 'zip(*[range(1000000)]*5)' 10 loops, best of 3: 496 msec per loop $ python -m timeit -s 'import gc; gc.enable()' 'zip(*[range(1000000)]*5)' 10 loops, best of 3: 2.93 sec per loop I remember that a similar issue was discussed some months ago: http://bugs.python.org/issue2607 In short: the gc is tuned for typical usage. If your usage of python is specific, use gc.setthreshold and increase its values.
For very large bursts of allocation, tuning is no different from disabling it outright, and disabling is simpler/more reliable.
-- Adam Olsen, aka Rhamphoryncus
- Previous message: [Python-Dev] C API for gc.enable() and gc.disable()
- Next message: [Python-Dev] C API for gc.enable() and gc.disable()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]