函数过早返回的效率

作为一个缺乏经验的程序员，我经常遇到这种情况，尤其是对于我要优化的一个雄心勃勃，速度密集的项目，我感到特别奇怪。对于主要的类C语言（C，objC，C ++，Java，C＃等）及其常用的编译器，这两个函数是否会同样高效地运行？编译后的代码有什么区别吗？

void foo1(bool flag)
{
    if (flag)
    {
        //Do stuff
        return;
    }

    //Do different stuff
}

void foo2(bool flag)
{
    if (flag)
    {
        //Do stuff
    }
    else
    {
        //Do different stuff
    }
}

基本上来说，提早break或return提早有过直接的效率红利/罚金吗？堆栈框架如何参与？是否有优化的特殊情况？是否有任何因素（例如内联或“内容”的大小）会对此产生重大影响？

我一直支持通过次要优化来提高可读性（我在参数验证中经常看到foo1），但是这种情况经常出现，因此我想一劳永逸地抛开所有烦恼。

而且我知道过早优化的陷阱...呃，那是一些痛苦的回忆。

编辑：我接受了一个答案，但是EJP的答案非常简洁地解释了为什么使用a return几乎可以忽略不计（在汇编中，return到函数末尾创建一个“分支”，这非常快。分支会更改PC寄存器和可能还会影响缓存和管道，这是很小的。）特别是在这种情况下，它实际上没有任何区别，因为if/else和和都return创建了到函数末尾的相同分支。

完全没有区别：

=====> cat test_return.cpp
extern void something();
extern void something2();

void test(bool b)
{
    if(b)
    {
        something();
    }
    else
        something2();
}
=====> cat test_return2.cpp
extern void something();
extern void something2();

void test(bool b)
{
    if(b)
    {
        something();
        return;
    }
    something2();
}
=====> rm -f test_return.s test_return2.s
=====> g++ -S test_return.cpp 
=====> g++ -S test_return2.cpp 
=====> diff test_return.s test_return2.s
=====> rm -f test_return.s test_return2.s
=====> clang++ -S test_return.cpp 
=====> clang++ -S test_return2.cpp 
=====> diff test_return.s test_return2.s
=====> 

意味着即使没有在两个编译器中进行优化，生成的代码也没有任何区别

简短的答案是，没有区别。帮自己一个忙，不要再为此担心。优化的编译器几乎总是比您聪明。

专注于可读性和可维护性。

如果要查看会发生什么，请在优化的基础上构建它们，然后查看汇编器输出。

有趣的答案：尽管到目前为止，我都同意所有这些观点，但是到目前为止，这个问题可能有一些涵义，这些涵义现在已经被完全忽略了。

如果上面的简单示例扩展了资源分配，然后进行了错误检查并可能释放资源，那么情况可能会发生变化。

考虑初学者可能采取的幼稚方法：

int func(..some parameters...) {
  res_a a = allocate_resource_a();
  if (!a) {
    return 1;
  }
  res_b b = allocate_resource_b();
  if (!b) {
    free_resource_a(a);
    return 2;
  }
  res_c c = allocate_resource_c();
  if (!c) {
    free_resource_b(b);
    free_resource_a(a);
    return 3;
  }

  do_work();

  free_resource_c(c);
  free_resource_b(b);
  free_resource_a(a);

  return 0;
}

上面的代码代表了过早返回的风格的极端版本​​。请注意，随着复杂性的增加，代码会随着时间变得非常重复且不可维护。如今，人们可能会使用异常处理来捕获这些异常。

int func(..some parameters...) {
  res_a a;
  res_b b;
  res_c c;

  try {
    a = allocate_resource_a(); # throws ExceptionResA
    b = allocate_resource_b(); # throws ExceptionResB
    c = allocate_resource_c(); # throws ExceptionResC
    do_work();
  }  
  catch (ExceptionBase e) {
    # Could use type of e here to distinguish and
    # use different catch phrases here
    # class ExceptionBase must be base class of ExceptionResA/B/C
    if (c) free_resource_c(c);
    if (b) free_resource_b(b);
    if (a) free_resource_a(a);
    throw e
  }
  return 0;
}

在查看下面的goto示例之后，Philip建议在上面的catch块内使用一个不间断的开关/外壳。可以先切换（typeof（e））然后掉入free_resourcex()调用，但这并不容易，需要进行设计考虑。请记住，没有中断的开关/外壳与下面带有菊花链标签的goto完全一样...

正如Mark B所指出的那样，在C ++中遵循资源获取即初始化原则（简称RAII）被认为是一种很好的风格。该概念的要点是使用对象实例化来获取资源。一旦对象超出范围并调用其析构函数，资源便会自动释放。对于相互依赖的资源，必须格外小心，以确保正确的解除分配顺序并设计对象类型，以使所需的数据可用于所有析构函数。

或者在例外前几天可能会做：

int func(..some parameters...) {
  res_a a = allocate_resource_a();
  res_b b = allocate_resource_b();
  res_c c = allocate_resource_c();
  if (a && b && c) {   
    do_work();
  }  
  if (c) free_resource_c(c);
  if (b) free_resource_b(b);
  if (a) free_resource_a(a);

  return 0;
}

但是，这个过于简化的示例有几个缺点：仅当分配的资源彼此不依赖时才可以使用它（例如，它不能用于分配内存，然后打开文件句柄，然后将数据从句柄读取到内存中），并且不提供单独的，可区分的错误代码作为返回值。

为了使代码保持快速（！），紧凑，易于阅读和可扩展的Linus Torvalds为内核代码实施了与资源相关的另一种样式，甚至以绝对合理的方式使用了臭名昭著的goto：

int func(..some parameters...) {
  res_a a;
  res_b b;
  res_c c;

  a = allocate_resource_a() || goto error_a;
  b = allocate_resource_b() || goto error_b;
  c = allocate_resource_c() || goto error_c;

  do_work();

error_c:
  free_resource_c(c);
error_b:
  free_resource_b(b);
error_a:
  free_resource_a(a);

  return 0;
}

关于内核邮件列表的讨论的要点是，大多数在goto语句上“首选”的语言功能都是隐式的gotos，例如巨大的树状if / else，异常处理程序，loop / break / continue语句等。在上面的示例中，goto被认为是可以的，因为它们仅跳跃了一小段距离，具有清晰的标签，并且释放了其他混乱的代码来跟踪错误情况。这个问题也在stackoverflow上进行了讨论。

但是，最后一个示例中缺少的是一种返回错误代码的好方法。我当时想result_code++在每次free_resource_x()调用后添加一个，然后返回该代码，但这抵消了上述编码样式的一些速度提升。如果成功，则很难返回0。也许我只是没有想象力;-)

所以，是的，我确实认为在编码过早返回与否之间存在很大的差异。但是我也认为，只有在更复杂或难以为编译器进行重构和优化的更复杂的代码中，这种情况才显而易见。一旦资源分配起作用，通常就是这种情况。

即使答案不多，生产编译器在优化方面也将比您做的更好。与这些类型的优化相比，我更倾向于可读性和可维护性。

具体来说，return它将被编译到方法末尾的一个分支中，在该分支中将有一条RET指令或可能存在的任何指令。如果省略它，则之前的代码块末尾else将被编译为一个到该代码else块末尾的分支。因此，您可以看到在这种特定情况下，它没有任何区别。

如果您真的想知道特定编译器和系统的编译代码是否有所不同，则必须自己编译并查看程序集。

但是，在大型方案中，几乎可以肯定的是，编译器的优化要比您的微调更好，即使不能这样做，对程序性能的影响也不大可能。

相反，应以最清晰的方式编写代码，以供人类阅读和维护，并让编译器执行其最擅长的工作：从源代码中生成最佳汇编。

在您的示例中，收益是显而易见的。当返回的页面是上/下/下两个页面（其中发生了不同的事情）时，调试人员会怎样？当有更多代码时，要查找/查看要难得多。

void foo1(bool flag)
{
    if (flag)
    {
        //Do stuff
        return;
    }

    //Do different stuff
}

void foo2(bool flag)
{
    if (flag)
    {
        //Do stuff
    }
    else
    {
        //Do different stuff
    }
}

我非常赞同blueshift：首先要具有可读性和可维护性！但是，如果您真的很担心（或者只是想了解编译器在做什么，从长远来看这绝对是个好主意），那么您应该自己找自己。

这将意味着使用反编译器或查看低级编译器输出（例如，汇编语言）。使用C＃或任何.Net语言，此处记录的工具将为您提供所需的工具。

但是正如您自己所观察到的，这可能是过早的优化。

摘自Clean Code：《敏捷软件技巧手册》

标志参数很丑陋。将布尔值传递给函数是一种非常糟糕的做法。它立即使该方法的签名复杂化，大声宣称此函数可以完成多项任务。如果标志为true，则执行一件事，如果标志为false，则另一件事！

foo(true);

代码中的内容只会使读者导航到该函数，而浪费时间阅读foo（boolean flag）

更好的结构化代码库将为您提供优化代码的更好机会。

一个想法（目前还不记得提议它的人）是，从结构的角度来看，所有函数都应该只有一个返回点，以使代码更易于阅读和调试。我想这更多是为了进行宗教辩论。

您可能希望控制函数何时以及如何退出以打破该规则的一个技术原因是在编写实时应用程序时，并且您要确保通过函数的所有控制路径都需要完成相同数量的时钟周期。

我很高兴您提出这个问题。您应该始终在早日返回时使用分支。为什么停在那里？如果可以的话，将所有功能合并为一个（至少可以）。如果没有递归，这是可行的。最后，您将拥有一个庞大的主要功能，但这就是您需要/想要的这类功能。然后，将您的标识符重命名为尽可能短的名称。这样，在执行代码时，花在阅读姓名上的时间就更少了。接下来做...