这段代码可以优化吗？

Question

我想我越来越痴迷于优化，所以我想知道以下代码是否可以“优化”：

假设我有一个 C 语言链表，在创建新元素时我使用以下代码：

log_event_list_cur->next = 
    (struct log_event_list *)malloc(sizeof(struct log_event_list));

log_event_list_cur = log_event_list_cur->next;

不知道下面的代码是否可以：

log_event_list_cur = 
    log_event_list_cur->next = 
        (struct log_event_list *) malloc(sizeof(struct log_event_list));

或：

log_event_list_cur->next = 
    log_event_list_cur=(struct log_event_list *) malloc....

问候！

Answer 1

是的，第一个很好（与第一个代码行为等效的正确代码），但优化都不是。它们将被编译成相同的机器代码。做你认为最易读的事情。

第二个行为不同，因为log_event_list_cur 在设置next 之前被分配给一个新的列表条目。

Answer 2

它不会有任何区别。无论如何，简单的赋值都会被编译器优化掉。

至少了解如何获取汇编代码的“要点”，以及如何从可执行文件中转储汇编输出。在 Linux 上，使用 objdump -S -d 将为您提供带有汇编程序的内联代码。

Answer 3

正如已经指出的，编译器可能会为所有三个版本生成相同的代码。

相反，如果您真的想让它更快，请实现一个空闲列表，即包含当前未使用的列表项的第二个列表。这样，“分配”一个新成员意味着只是从空闲列表中弹出一个项目（类似地“释放”意味着简单地将项目推到空闲列表中）。这样，您就没有每个​​新“分配”的 malloc/free 开销。显然，如果空闲列表为空并且您需要分配一个新成员，则无论如何您都必须调用malloc，但希望这种情况很少发生。

顺便说一句，我希望你只是省略了对malloc 的返回值的检查。否则，如果malloc 返回 NULL，那么您很快就会崩溃……

Answer 4

停止沉迷于优化，开始沉迷于可读性。 过早的优化是万恶之源。

第一个代码片段没问题。很清楚发生了什么。链表在当前条目之后得到一个新条目（可能是最后一个条目），然后将当前条目向前移动成为最后一个。

要理解第二个片段中发生的事情要困难得多。它最终与第一个示例相同，但需要付出脑力才能确保它确实如此。

第三个片段全错了，它是一个完美的例子，说明为什么你甚至不应该在开始考虑优化之前就开始考虑优化。把它做好，然后让它变得快，只有当你亲眼看到冷酷的分析器数据时才做后者。

Answer 5

正如其他答案中提到的，编译器应该能够优化您显示的任何差异；为了可读性，我可能会选择第一个，而且为了可读性，我可能会设置一个 #define （或在更高版本的 C 中设置一个 const ），其值为您的 sizeof 调用，以及您的 typedef struct 将大小压缩一点。

[编辑：根据对该问题的评论，演员阵容甚至没有必要，已删除。]

[编辑：根据对问题 sizeof(log_node) as a const 的另一条评论不再有意义；当它是c_log_node_size 与sizeof(struct log_event_list) 时，它（有点）做到了，但现在它完全是愚蠢的。 （如评论中所述，还有其他很好的理由不这样做，也许 sizeof_c_log_node 可以吗？不不不。）：D]

typedef struct log_event_list log_node

然后就变成了：

log_event_list_cur->next = malloc(sizeof(log_node));
log_event_list_cur = log_event_list_cur->next;

如果您想对代码的这个特定部分进行一些优化，首先我建议您对系统进行一些分析，以确保它实际上是一个瓶颈。如果它没有引起问题，那么就不需要优化，你花在优化上的任何时间都最好花在其他地方，因为无论如何它都没有任何区别。可能有些东西可以使用优化，但可能不是这样。但是，考虑到这个特定的代码块，唯一想到的就是优化块的分配。

我开始为此编写一些代码，但我没有离开它，因为我意识到根本没有必要在这个上重新发明轮子，除了它很有趣。如果您发现优化那段代码很有价值，这里是possibility for tweaking your allocations: vmalloc。除非你真的能证明它是一个瓶颈，否则我不会搞砸它。不过想想还是挺不错的。 :)