• thingsiplay@beehaw.org
    link
    fedilink
    arrow-up
    6
    ·
    5 hours ago
    • The fastest code is the code you don’t run.

    Not really. The code can be slow, even if I do not run it. Also, sometimes additional code can do optimization (like caching), which is more code = faster. Or additional libraries, complexity and code paths can in example add multicore execution, which could speed up. So, I do not buy the less code is faster logic.

    • Malgas@beehaw.org
      link
      fedilink
      English
      arrow-up
      4
      ·
      3 hours ago

      I think the most obvious example is loop unrolling. An unrolled loop can be many times more code, but runs faster because you’re not updating a counter or doing conditional jumps.

    • Voytrekk@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      6
      ·
      5 hours ago

      I think it really depends on what your code is doing. I do agree that less isn’t always faster or as they mentioned in the post, safer. Taking a raw input is fast, but not very safe for a variety of reasons. I personally make “simple to understand” as the highest priority for my code.

      • thingsiplay@beehaw.org
        link
        fedilink
        arrow-up
        2
        ·
        4 hours ago

        On a slightly different example, the suckless project has a huge emphasizes on lightweight code, which they call “suckless”. I don’t think in this case faster is the goal, but having less code and be simple as possible (not even configuration files allowed, you just recompile program) and almost no documentation in the code either. But the idea is the same, of having “lightweight” code.