• PattyMcB@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    ·
    4 days ago

    I appreciate the large amount of info. Great answer. It just doesn’t make sense to me, all things being equal (including performant algorithms), why choose Python and then make a small performance tweak like in the article? I understand preferring the faster implementation, but it seems to me like waxing your car to reduce wind resistance to make it go faster, when installing a turbo-charger would be much more effective.

    • Teanut@lemmy.world
      link
      fedilink
      English
      arrow-up
      16
      ·
      4 days ago

      If you use the profiler and see that the slower operation is being used frequently, and is taking up a chunk of time deemed significant, why not swap it to the faster version?

      In a simulation I’m working on that goes through 42 million rounds I spent some time profiling and going through the code that was eating up a lot of time (especially things executed all 42 million times) and trying to find some optimizations. Brought the run time down from about 10 minutes to 5 minutes.

      I certainly wasn’t going to start over in C++ or Rust, and if I’d started with either of those languages I would have missed out on a lot of really strong Python libraries and probably spent more time coding rather than refining the simulation.

    • lengau@midwest.social
      link
      fedilink
      English
      arrow-up
      9
      ·
      4 days ago

      I think a better analogy would be that you’re tuning your bike for better performance because the trade-offs of switching to a car are worse than keeping the bike.

    • 0ops@lemm.ee
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 days ago

      If anything, to me it seems more important for a slower language to be optimized. Ideally everything would be perfectly optimized, but over-optimization is a thing: making optimizations that aren’t economical. Even though c is many times faster than python, for many projects it’s fast enough that it makes no practical difference to the user. They’re not going to bitch about a function taking 0.1 seconds to execute instead of 0.001, but they might start to care when that becomes 100 seconds vs 1. As the program becomes more time intensive to run, the python code is going to hit that threshold where the user starts to notice before c, so economically, the python would need to be optimized first.

    • orcrist@lemm.ee
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 days ago

      It is a small performance tweak if done once, right? But let’s suppose people worried about refactoring here would have checked to see what areas of their code are seeing heavy use.