3 ms·

The GIL improves single-threaded performance compared to other options.

• tomn 4y ago
  Maybe i should have explained this.. To share objects between threads, some synchronisation is needed, for example to update reference counts. There are a few ways to do this: - make the user add locks; the problem with this if it goes wrong it can crash the interpreter and make it impossible to debug the problem from within python, which is not user-friendly, and lots of existing code will break. Competent users are already doing this though, so it's nearly free. - add fine-grained locking/synchronisation for object internals within the interpreter. This slows everything down, even if you're not using threads. - Lock the whole interpreter state whenever a thread is running. This makes threads less useful (no speed-up from threading pure-python code that isn't doing IO; you have to use multiprocessing for that), but it's cheap as you only need to lock/unlock when you're doing something slow anyway (IO, thread switching, native code). I think this explains why GIL removal has not been successful yet despite much work: the alternatives slow down single-threaded code, which is not worth it when nearly all sensible uses of threading don't benefit either.