Dirk Meyer wrote: > see that threading doesn't slow down things. Second (very strange): > when no thread is running, but threading itself is active, it is > slower. But still, not much.
The GIL isn't initialized until a thread is created (or a C module explicitly initializes it, as in the case of kaa-xine). So in common, non-thread cases, the GIL isn't used at all, so that overhead is avoided. Once a thread has started, the GIL is initialized and so it must be acquired/released at certain points. Anyway, your test probably isn't very good, but I think it's good enough for testing the impact threads have in programs like Freevo. It's just intuitively obvious there's going to be some overhead because to the GIL, but for the kinds of things we'll be using threads for, it's not a big deal. So Python threads are good for getting around blocking operations, but not very good for parallizing tasks on SMP boxes. I ran your test on my SMP box (dual P3 800) and got these results: Normal operation: 142.627851009 secs Threading operation: 144.94809103 secs Normal operation with threading: 137.823442936 secs All the work in your test is in Python space, so the GIL prevents any useful parallization from happening. Jason.
signature.asc
Description: OpenPGP digital signature
