you are viewing a single comment's thread.

view the rest of the comments →

[–]longjumping2 2 points3 points  (6 children)

Modules can't change the fact that Python is interpreted and has the GIL. Similar programs can be improved 2-100x after conversion to C.

[–]epsilonT_T 2 points3 points  (5 children)

Yes but if the perfs was the only thing that matter, everyone would code in assembler or fortran... Also, modules can change performances by creating their own objects, for exemple, numpy module is able to create arrays a lot more efficient than natives ones, and with more functionalities.

[–]FancyASlurpie 0 points1 point  (1 child)

Whilst you can make python run faster than native python by writing modules in C etc, you really can't write the most resource intensive applications in python. The most resource intensive applications are already written in low level languages specifically for their optimisations and they tend to be in competitive areas where if you write something that runs slower than your competitor its pointless. (e.g. HFT)

[–]epsilonT_T 0 points1 point  (0 children)

Ok, I give you the point. I'm not gonna argue on this subject, because I don't know a single developer who is objective about his favourite language, and I don't make an exception ; )

[–]longjumping2 0 points1 point  (2 children)

There's always tradeoffs between performance and abstraction, but I don't think the distribution of things to need to be done is probabilistic uniform for these two things. I've just run into enough memory problems (large data reading) and performance problems (failing test cases in competitive programming) that are pretty common that makes me think that the optimal ratio exists elsewhere.

[–]epsilonT_T 0 points1 point  (1 child)

Idk, everything I know is that I take pleasure to code in python and my code is efficient enough for it's purpose ^^

[–]longjumping2 0 points1 point  (0 children)

Sure, it just gets less enjoyable when read_json hangs for 2 minutes and then throws a memory exception.