Must I think about compiled machine code when I write my code?

Question

For example I've got following code:

auto z = [](int x) -> int {
    if (x > 0) {
        switch (x) {
            case 2: return 5;
            case 3: return 6;
            default: return 1;
            }
        }
    return 0;
    };

And later I call this several times. In asm code I see external calls with lambda....something... It's becoming not easy to read and I think it also can cause performance. So maybe I win in meta-programming but do I lose in asm debugging and performance? Should I avoid modern language features, macros and other meta programming aspects to be sure in performance and debugging simplicity?

Answer 1

Must I think about compiled machine code when I write my code?

No, not when you write your code the first time and don't suffer from any real, measurable performance problems. For most tasks, this is the standard case. Thinking too early about optimization is called "premature optimization", and there are good reasons why D. Knuth called that "the root of all evil".

Yes, when you measure a real, provable performance bottleneck, and you identify that specific lambda construct as the root cause. In this case, it may a good idea to remember Joel Spolsky's "law of leaky abstractions" and think about what might happen at the asm level. But beware, you may be astonished how small the performance increasement will be when you replace a lambda construct by a "not so modern" language construct (at least, when using a decent C++ compiler).

Answer 2

The choice between lambda and functor-class is a tradeoff.

The gain from lambda is mostly syntactic, by minimizing the amount of boilerplate and allowing conceptually-related code to be written inline, inside the function that is going to utilize it (immediately or later).

Performance-wise, this is no worse than a functor class, which is a C++ struct or class that contains a single "method". In fact, compilers treat lambda no differently than a compiler-generated functor class behind the scene.

// define the functor method somewhere
struct some_computer_generated_gibberish_0123456789
{
    int operator() (int x) const
    {
        if (x == 2) return 5;
        if (x == 3) return 6;
        return 0;
    }
};

// make a call
some_computer_generated_gibberish_0123456789 an_instance_of_0123456789;
int outputValue = an_instance_of_0123456789(inputValue);

In your code example, performance-wise it is no different from a function call, because that functor class happen to have no state (because it has an empty capture clause), thus requiring no allocation, constructor nor destruction.

int some_computer_generated_gibberish_0123456789_method_more_gibberish(int x)
{
    if (...) return ...;
    return ...;
}

Debugging any non-trivial C++ code using a disassembler has always been a difficult task. This is true with or without using lambda. This is caused by the sophisticated code optimization by C++ compiler that resulted in reordering, interleaving and dead code elimination.

The name-mangling aspect is somewhat unpalatable, and debugger support for lambda is still in its infancy. It can only be hoped that debugger support will improve over time.

Currently, the best way to debug lambda code is to use a debugger that supports setting breakpoints at the source code level, i.e. by specifying the source file name and the line number.

Answer 3

To add to the answer by @DocBrown, remember that these days CPU's are cheap but labour is expensive.

In the overall cost of a program, hardware is usually trivial in comparison to the cost of maintenance, which is by far the most expensive part of a typical project (even more than its development).

Therefore, your code needs to optimise maintenance above everything else, except when performance is critical (and even then maintenance needs to be considered).