为什么 switch 比 if 快

IT小君   2021-09-26T06:34:42

许多 Java 书籍都将switch语句描述为比if else语句更快但我没有发现为什么 switch 比 if 快

例子

我有一种情况,我必须从两项中选择一项。我可以使用任何一种使用

switch (item) {
    case BREAD:
        //eat Bread
        break;
    default:
        //leave the restaurant
}

或者

if (item == BREAD) {
    //eat Bread
} else {
    //leave the restaurant
}

考虑到 item 和 BREAD 是一个常量 int 值。

在上面的例子中哪个动作更快,为什么?

点击广告,支持我们为你提供更好的服务
评论(5)
IT小君

因此,如果您计划拥有大量数据包,那么现在内存并不是一个很大的成本,而且数组非常快。您也不能依赖 switch 语句来自动生成跳转表,因此自己生成跳转表场景会更容易。正如您在下面的示例中看到的,我们假设最多 255 个数据包。

为了得到下面的结果,你需要抽象......我不会解释它是如何工作的,所以希望你对此有所了解。

如果您需要更多,我将其更新为将数据包大小设置为 255,然后您必须对 (id < 0) || 进行边界检查 (ID > 长度)。

Packets[] packets = new Packets[255];

static {
     packets[0] = new Login(6);
     packets[2] = new Logout(8);
     packets[4] = new GetMessage(1);
     packets[8] = new AddFriend(0);
     packets[11] = new JoinGroupChat(7); // etc... not going to finish.
}

public void handlePacket(IncomingData data)
{
    int id = data.readByte() & 0xFF; //Secure value to 0-255.

    if (packet[id] == null)
        return; //Leave if packet is unhandled.

    packets[id].execute(data);
}

编辑因为我在 C++ 中使用了很多跳转表,现在我将展示一个函数指针跳转表的例子。这是一个非常通用的示例,但我确实运行了它并且它工作正常。请记住,您必须将指针设置为 NULL,C++ 不会像在 Java 中那样自动执行此操作。

#include <iostream>

struct Packet
{
    void(*execute)() = NULL;
};

Packet incoming_packet[255];
uint8_t test_value = 0;

void A() 
{ 
    std::cout << "I'm the 1st test.\n";
}

void B() 
{ 
    std::cout << "I'm the 2nd test.\n";
}

void Empty() 
{ 

}

void Update()
{
    if (incoming_packet[test_value].execute == NULL)
        return;

    incoming_packet[test_value].execute();
}

void InitializePackets()
{
    incoming_packet[0].execute = A;
    incoming_packet[2].execute = B;
    incoming_packet[6].execute = A;
    incoming_packet[9].execute = Empty;
}

int main()
{
    InitializePackets();

    for (int i = 0; i < 512; ++i)
    {
        Update();
        ++test_value;
    }
    system("pause");
    return 0;
}

另外我想提的另一点是著名的分而治之。所以我上面 255 个数组的想法可以减少到不超过 8 个 if 语句作为最坏的情况。

即但请记住,它会变得混乱且难以快速管理,而我的其他方法通常更好,但这在数组无法削减它的情况下使用。您必须弄清楚您的用例以及每种情况何时效果最佳。就像如果您只有一些检查,您就不会想要使用这两种方法中的任何一种一样。

If (Value >= 128)
{
   if (Value >= 192)
   {
        if (Value >= 224)
        {
             if (Value >= 240)
             {
                  if (Value >= 248)
                  {
                      if (Value >= 252)
                      {
                          if (Value >= 254)
                          {
                              if (value == 255)
                              {

                              } else {

                              }
                          }
                      }
                  }
             }      
        }
   }
}
2021-09-26T06:34:43   回复
IT小君

因为有特殊的字节码可以在很多情况下进行高效的 switch 语句评估。

如果使用 IF 语句实现,您将进行检查、跳转到下一个子句、检查、跳转到下一个子句等等。使用 switch JVM 加载要比较的值并遍历值表以找到匹配项,这在大多数情况下会更快。

2021-09-26T06:34:43   回复
IT小君

一个switch说法是并不总是比一个快if言。它比一长串if-else语句具有更好的扩展性,因为它switch可以根据所有值执行查找。但是,在短时间内,它不会更快,而且可能会更慢。

2021-09-26T06:34:43   回复
IT小君

当前JVM有两种开关字节码:LookupSwitch和TableSwitch。

switch 语句中的每个 case 都有一个整数偏移量,如果这些偏移量是连续的(或大部分是连续的,没有大的间隙)(case 0:case 1:case 2 等),则使用 TableSwitch。

如果偏移量以大间隙展开(案例 0:案例 400:案例 93748:等),则使用 LookupSwitch。

简而言之,区别在于 TableSwitch 是在恒定时间内完成的,因为可能值范围内的每个值都被赋予了特定的字节码偏移量。因此,当您为语句提供 3 的偏移量时,它知道向前跳 3 以找到正确的分支。

查找开关使用二进制搜索来查找正确的代码分支。这在 O(log n) 时间内运行,这仍然很好,但不是最好的。

有关这方面的更多信息,请参见此处:JVM 的 LookupSwitch 和 TableSwitch 之间的区别?

因此,至于哪个最快,请使用这种方法:如果您有 3 个或更多值连续或接近连续的案例,请始终使用 switch。

如果您有 2 种情况,请使用 if 语句。

对于任何其他情况, switch 很可能更快,但不能保证,因为 LookupSwitch 中的二分搜索可能会遇到糟糕的情况。

此外,请记住,JVM 将对 if 语句运行 JIT 优化,这些语句将尝试将最热的分支放在代码中的最前面。这称为“分支预测”。有关这方面的更多信息,请参见此处:https : //dzone.com/articles/branch-prediction-in-java

您的经历可能会有所不同。我不知道 JVM 没有在 LookupSwitch 上运行类似的优化,但我已经学会信任 JIT 优化而不是试图超越编译器。

2021-09-26T06:34:43   回复
IT小君

在字节码级别,主体变量从Runtime加载的结构化.class文件中的内存地址只加载一次到处理器寄存器中,这是在switch语句中;而在 if 语句中,您的代码编译 DE 会生成不同的 jvm 指令,这需要将每个变量加载到寄存器中,尽管使用与下一个前面的 if 语句中相同的变量。如果您知道用汇编语言编码,那么这将是司空见惯的;java编译的cox虽然不是字节码,也不是直接的机器码,但是这里的条件概念还是一致的。好吧,我试图在解释时避免更深层次的技术性。我希望我已经清楚地说明了这个概念并揭开了神秘面纱。谢谢你。

2021-09-26T06:34:44   回复