3 ms·
Python is not a language for writing fast code. Python is a relaxed language for things that don’t have to be fast. If you need something to be fast you are sup
by zarzavat 3y ago
Python is not a language for writing fast code. Python is a relaxed language for things that don’t have to be fast. If you need something to be fast you are supposed to use a C extension and control it with Python - that’s been the dogma for as long as I can remember to avoid exactly this kind of pathological race to performance in a language that was never designed for it.
By using Python you are already leaving a ton of performance on the table in single-threaded code compared to a fast, compiled language.
- deleted 3y ago[deleted]
- tgv 3y agoYup. I don't know why you would insist on having multiple Python threads, especially given the high risks. Python is only suitable for coordinating/scripting large libraries written in other languages or for quick and easy development. Python programs should not reach the stage where their use in production is hampered by lack of multi-threading.
- gjulianm 3y agoIt's always a tradeoff, but I'm surprised to see so many people say that just because Python isn't fast it shouldn't get multithreading. Yes, by using Python we leave a lot of performance on the table. We also get a lot of dev performance, just because of the amount of libraries available, dynamic language features, quick development.. So it's not always a clear decision between Python or a compiled language. > If you need something to be fast you are supposed to use a C extension and control it with Python So what do we do with the case where we need to control the C extension from multiple threads? Because that's currently my problem. The C extension we developed do release the GIL, but because the Python code that does the calls to the extension can't be really multithreaded, the performance gain we get is minimal.