5 ms·

There's also the argument that at a certain scale the time of a developer is simply more expensive than time on a server. If I write something in C++ that does

• eska 4y ago
  If Python was merely twice as slow then I could agree with you.
  • bombolo 4y ago
    Not all code needs to process terabytes of data. I have code running that reads ~20 bytes, checks the internal status on an hashmap and flips a bit. Would it be faster in C? Of course. Would it have taken me much longer to write to achieve absolutely no benefit? Yes.
• dagw 4y ago
  Realistically something that takes 1 second in C++ will take 10 seconds (if you write efficient python and lean heavily on fast libraries) to 10 minutes in python. But the rest of your point stands
  • joenot443 4y ago
    Damn! Is the rule of thumb really a 10x performance hit between Python/C++? I don’t doubt you’re correct, I’m just thinking of all the unnecessary cycles I put my poor CPU through.
    • benji-york 4y ago
      As a long-time Python lover, yes that's a decent rule of thumb.
    • moffkalast 4y ago
      Well at least 10x, sometimes more. Not really surprising when you think about that it's a VM reading and parsing your code as a string at runtime.
      • bombolo 4y ago
        > it's a VM reading and parsing your code as a string at runtime. Commonly it creates the .pyc files, so it doesn't really re-parse your code as a string every time. But it does check the file's dates to make sure that the .pyc file is up to date. On debian (and I guess most distributions) the .pyc files get created when you install the package, because generally they go in /usr and that's only writeable by root. It does include the full parser in the runtime, but I'd expect most code to not be re-parsed entirely at every start. The import thing is really slow anyway. People writing command lines have to defer imports to avoid huge startup times to load libraries that are perhaps needed just by some functions that might not even be used in that particular run.
        • kaba0 4y ago
          > re-parse your code as a string every time That doesn’t really take any significant time though on modern processors.
        • moffkalast 4y ago
          Aren't those pyc files still technically just string bytecode, but encoded as hex?
          • bombolo 4y ago
            Well bytecode isn't the same as the actual code you write in your editor.
  • bombolo 4y ago
    If the 1 second is spent waiting for IO, it will take 1 second in whatever language. But yes python is slow. However I've seen good python code be faster than bad C code.
    • roflyear 4y ago
      Well, to be fair the "good python code" is probably just executing something written in c lol. But lots of python is backed up by stuff written in c.
      • bombolo 4y ago
        Not necessarily. Just using a better optimized sort or hash algorithm can make a big difference. I was talking specifically of pure python code (except the python's standard library itself, where it really is unavoidable).
    • kaba0 4y ago
      Of course algorithmic complexity will trump anything else at big enough n values.
  • Gasp0de 4y ago
    And how much code is generally written that actually is compute heavy? All the code I've ever written in my job is putting and retrieving data in databases and doing some basic calculations or decisions based on it.
    • Yoric 4y ago
      That is absolutely true. But sometimes, you do end up writing that compute heavy piece of code. At that stage, you have to learn how to write your own native library :) Speaking of which, I've written some Python modules in Rust using PyO3, its' a very agreeable experience.
    • jimbokun 4y ago
      Rule of thumb: Code is "compute heavy" (could equally be memory heavy or IOPs heavy) if it's deployed into many servers or "the cloud" and many instances of it are running serving a lot of requests to a lot of users. Then the finance people start to notice how much you are paying for those servers and suddenly serving the same number of users with less hardware becomes very significant for the company's bottom line. The other big one is reducing notable latency for users of your software.
  • roflyear 4y ago
    Not for everything. There are plenty of Python operations that are not 10x slower than c.
    • dagw 4y ago
      That is true, but there are relatively few real world applications that consist of only those operations. In the example I mentioned below, there where actually some parts of my python rewrite that ended up faster than the original C++ code, but once everything was strung together into a complete application those parts where swamped by the slow parts.
      • ghostwriter 4y ago
        Most of the time these are arithmetic tight loops that require optimisations, and it's easy to extract those into separate compiled cython modules without losing overal cohesion within the same Python ecosystem.
  • giantrobot 4y ago
    I spend most of my time waiting on IO, something like C++ isn't going to improve my performance much. If C++ takes 1ms to transform data and my Python code takes 10ms, it's not much of a win for me when I'm waiting 100ms for IO. With Python I can write and test on a Mac or Windows and easily deploy on Linux. I can iterate quickly and if I really need "performance" I can throw bigger or more VPSes at the problem with little extra cognitive load. I do not have anywhere near the same flexibility and low cognitive load with C++. The better performance is nice but for almost everything I do day to day completely unnecessary and not worth the effort. My case isn't all cases, C++ (or whatever compiled language you pick) will be a win for some people but not for me.
• mharig 4y ago
  Speeding up the time critical parts with Cython or Numba or ... is rather easy.