20

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?

cnd
  • 1,874
  • 1
  • 14
  • 19
  • 1
    Depending on the version of compiler and its bundled standard library, lambda may indeed be implemented inefficiently. See [this question](http://stackoverflow.com/questions/8203211/how-can-i-make-the-storage-of-c-lambda-objects-more-efficient) on Stackoverflow. However, the responsibility for improvement should lie on the compiler vendor. – rwong Jul 08 '13 at 06:19
  • 18
    You shouldn't need to debug assembly code, unless you are in performances critical path. Also, "clean code" != "good performances". – BЈовић Jul 08 '13 at 07:41
  • 1
    Fix your indentation please. I tried to do it, but it seems you can't edit just whitespace. – Christoffer Hammarström Jul 08 '13 at 08:51
  • @ChristofferHammarström fixed – cnd Jul 08 '13 at 09:00
  • @Heather: The closing braces still weren't aligned, i fixed them. – Christoffer Hammarström Jul 08 '13 at 09:26
  • @ChristofferHammarström Thank you but rolled the change back. Closing braces are very fine for me. – cnd Jul 08 '13 at 09:40
  • 1
    For you, maybe. But your way is nonstandard, and for me it was confusing and took me far longer to read the code than necessary. Write code for other programmers, not for yourself. – Christoffer Hammarström Jul 08 '13 at 10:38
  • @ChristofferHammarström which standard do you mean? Does StackOverflow has own code formatting standard? – cnd Jul 08 '13 at 11:04
  • 4
    @Heather: You appear to be using [Ratliff style](http://en.wikipedia.org/wiki/Indent_style#Ratliff_style), which i've never seen before and find hard to read. It's certainly one of the lesser known ones. My impression was that you hadn't indented properly. Nevermind then if you find it readable, i just disagree. – Christoffer Hammarström Jul 08 '13 at 12:23
  • 1
    The `if` is completely redundant in the example code, and while the compiler will probably catch that there is no reason to tempt a bad branch prediction. – dmckee --- ex-moderator kitten Jul 08 '13 at 12:44
  • @dmckee right, fixed. – cnd Jul 08 '13 at 12:50

3 Answers3

59

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).

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
8

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.

rwong
  • 16,695
  • 3
  • 33
  • 81
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).

Paddy Landau
  • 131
  • 3
  • Only partly true. If your code runs O(n^2) (quadratic) and you can make it something better say O(log(n)) (logarithmic) then hardware will never have a much performance increase as changing the code. In the case specified by the original poster this is very unlikely. – gnash117 Jul 12 '13 at 18:25
  • @gnash117 — yes, you are right if the code is to be run many times; thank you for pointing this out. In such cases, documenting the code clearly will keep it maintainable while allowing the performance improvement. – Paddy Landau Jul 12 '13 at 18:41
  • "labor is expensive" - Correct. Your customer's time is very important and often expensive. – Cerad Aug 03 '13 at 20:13