• FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    16 hours ago

    They mean measure first, then optimize.

    This is also bad advice. In fact I would bet money that nobody who says that actually always follows it.

    Really there are two things that can happen:

    1. You are trying to optimise performance. In this case you obviously measure using a profiler because that’s by far the easiest way to find places that are slow in a program. It’s not the only way though! This only really works for micro optimisations - you can’t profile your way to architectural improvements. Nicholas Nethercote’s posts about speeding up the Rust compiler are a great example of this.

    2. Writing new code. Almost nobody measures code while they’re writing it. At best you’ll have a CI benchmark (the Rust compiler has this). But while you’re actually writing the code it’s mostly find just to use your intuition. Preallocate vectors. Don’t write O(N^2) code. Use HashSet etc. There are plenty of things that good programmers can be sure enough are the right way to do it that you don’t need to constantly second guess yourself.