Message78646
| Author |
darrenr |
| Recipients |
darrenr |
| Date |
2008年12月31日.19:34:41 |
| SpamBayes Score |
8.8515705e-08 |
| Marked as misclassified |
No |
| Message-id |
<1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Python's garbage collector holds GIL during collection and doesn't
provide any method of interruption or concurrency with other Python
threads within a single Python VM. This can be a problem for realtime
applications. The worst-case performance of the garbage collector takes
linear time with respect to the number of Python objects that could
potentially be involved in a garbage cycle. I've attached timings taken
on a Core 2 Quad 2.4 GHz (WinXP Pro, 3GB RAM), with ever-increasing
numbers of objects. The gc at worst takes upwards of 3 seconds before
the process runs out of memory.
If gc periodically released the GIL it would allow it to be put in a
separate thread, but as it stands it blocks the Python VM for periods of
time that are too long for realtime interactive applications.
Alternatively a gc that is incremental by default would eliminate the
need for a second thread. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2008年12月31日 19:34:46 | darrenr | set | recipients:
+ darrenr |
| 2008年12月31日 19:34:46 | darrenr | set | messageid: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za> |
| 2008年12月31日 19:34:44 | darrenr | link | issue4794 messages |
| 2008年12月31日 19:34:41 | darrenr | create |
|