使用protobuf（谷歌的PROTOcol BUFfer），我需要"goto"一段逻辑来处理接收到的相应类型的消息。应该有很多类型的消息，关于这一点，我提出了两种"goto"方法：
-
by function子句，带有与message_type匹配的guard；
-
以message_type为键设置ETS，然后在ETS中存储Module和Fun的位置应用（Module，Fun）。
现在我怀疑#1是O（n），因为涉及到复杂的警卫，而毫无疑问地查找ETS O（1）。
你怎么说？
这听起来像是过早优化。优化肯定应该在分析代码之后进行。我强烈建议您支持代码维护而不是优化，直到代码被认为太慢，出于这个原因，我个人会选择函数子句。
尽管如此，您可能会喜欢《效率指南》，特别是关于函数子句的一章。在许多情况下，它们是由编译器优化的。
是什么让你认为apply不会有O（n）效率？每次实施的固定成本是多少？
首先，在您的情况下，n或多或少是恒定的（函数或事例的数量）。因此，您不应该比较大的O符号，而应该比较给定n的实际成本。
最明显的是O（1），它基本上说你的成本不会随着问题的规模而增长；但它并没有说你没有任何常量，或者你的成本很小。尽管如此，在n小于1000的情况下，您可能会使用比O（n）更多的资源。
最后，您应该查看的是实际数据。试着对这两种解决方案进行基准测试，看看哪一种看起来更快。或者更好的方法是，使用简单的方法，在性能下降后开始担心。只是不要试图修复那些不必修复的东西。
就我个人而言，函数子句会更快。使用ETS，您可能会遇到多个进程之间的并发读取问题（即使启用了脏读取）。