这两个节目的表演是一样的吗？

Question

例如，假设您有一个链表 1->2->3->4->5->6->NULL 并且您想要计算该链表的偶数索引的总和（假设第一个index从1开始，链表大小为偶数）

第一种方法

int total = 0;
int count = 0;
Node *ptr = head;
while(ptr != NULL)
{
    if(count % 2 == 0)
     {
       total += ptr->data;
     }
     count++;
     ptr = ptr->next;
}
 

第二种方法

int total = 0;
Node *ptr = head;
while(ptr != NULL)
{  
    total += ptr->data;
     ptr = ptr->next->next;
}

那么在我做了这两种方法之后，它们的性能是否相同？

Answer 1

我再次阅读了您的问题，并会回答 可能第二种方法稍微快一些。

现在，cmets 部分立即强调它也更危险。您实际上已指定假设列表中的节点数是偶数。如果这是一个有保证且可执行的前提条件，那么在技术上这样做是可以的。

即使是一个聪明的优化编译器也无法知道这个偶数列表长度的前提条件，所以它可能实现的最好的结果是认识到count 仅用于控制total 是否被更新等等循环可以展开如下：

// Possible automatic compiler optimization of First Approach
while (ptr)
{
    total += ptr->data;
    ptr = ptr->next;

    // Skip over every second node
    if (ptr) ptr = ptr->next;
}

基本而言，我们现在拥有的每个循环迭代比您的第二种方法多一个指针测试（分支）。这会产生更多指令（特别是分支指令），因此代码在技术上会（稍微）慢一些。

当然，这带来的实际影响可能很小。您的主要瓶颈是指针间接并从内存中获取，而不是指针测试本身。如果每个节点使用的内存大部分不是连续的，那么您将在大型列表上遇到缓存问题（实际上这会影响性能大约 100 倍）。

以上所有内容我的意思是，基于偶数列表长度的前提条件的特殊优化的好处是收益递减。

考虑到它本质上是不安全的，除非在代码中有很好的记录和/或受列表“均匀性”测试保护（如果您将节点数存储在某处），我建议使用您的第一种方法进行防御性编码或使用我的等效和（可以说）更整洁的版本。