大型 switch 语句和效率答案

【问题标题】：Large Switch Statements And Efficiency大型 switch 语句和效率
【发布时间】：2010-09-09 10:40:01
【问题描述】：

我请了一天假，努力研究内存管理和 opengl-es 以尝试提高效率。我们正在开发的应用程序的一部分可以访问大量数据表。这些数据主要以 switch 语句的形式提供给我们。

总的来说，我有四个 switch 语句，每个语句都有 2000 多个案例，预计会增长。这些的访问时间会有多差？现在是否值得寻找更容易实现的优化成果，或者这对 Objective-C 编译器来说是一个很大的禁忌？

【问题讨论】：

【解决方案1】：

Switch case 通常很快，因为它们只进行整数比较。

如果您真的想进行微优化，可以将某些类型的数据存储在 C 数组中，以便使用指针算法进行极快的查找。只有当你真的需要额外的速度时，你才应该考虑这一点 - 指针算法涉及很多潜在的错误，其中许多可能很难调试。

真正的问题是：您是否进行了任何分析？在对 iOS 应用程序进行时间分析时，Shark 是一个非常有效的工具 - 使用它，看看你的 switch case 代码花费了多少执行时间。如果低于 5-10%，则可能甚至考虑优化都没有意义。

【讨论】：

它似乎不到 10%，我认为大约是 7%，但我们将应用程序生成的每个工件称为 100,000 次（而且我们几乎不断地生产这些工件，一个接一个。它/似乎/不是瓶颈，但我觉得它已经够乱了。
正如其他人所说，首先分析应用程序。不要仅仅为了重构而重构事物。重构它，因为你有一个令人信服的理由在代码中修复一个缺陷。尽管重构的前提是在不改变其行为的情况下更改代码，但每次重构都有可能引入缺陷。我会等到它变得必要来重构它。如果它没有坏，就不要修理它。