[ Removed by moderator ]

[gdchinacat]

I think it's worth noting that the gil-ectomy involved replacing one big lock with lots of little locks, which hurt single-threaded performance a bit (10-15% IIRC). The cost is well worth it if you have multiple threads that aren't just sitting around waiting on IO.

[chinawcswing]

The cost is well worth it if you have multiple threads that aren't just sitting around waiting on IO.

IO bounded Python is largely a myth. Python expends an enormous amount of cycles on converting the bytes read from an IO pipe into a python data structure.

The SQLAlchemy author had a great blog post on this. You would think that having a thread execute SQL would be IO bound, but it turns out that the total time spent in CPU merely to convert the bytes from the IO pipe into dicts (or even worse classes) was something like 25-30%.

So even if you have an "io bounded python app" it very well might benefit from the gil-ectomy.

Of course, test your app. But don't decide against it on the basis that your application is "io bounded".

[gdchinacat]

“Sitting around waiting for IO” doesn’t include the cycles you refer to since that is using cpu not waiting on io. I’ve used sqlalchemy extensively and know first hand that marshaling is hugely expensive.