@hoosin 对

@cirton 加油

@qwingmix 回归谈不上，以前来的也不多，也没有说再也不来啥的

@LokiSharp 很久不上了，今天被骂了，就上来看看

@Epsil0n9 en，大家一起加油就是了。我现在早就看淡了

@Epsil0n9 没事儿，谢谢

@mazai 谢谢

欢迎看完再喷…居然被转了过来

@isaced 嗯，这个代码才 500 行，目前这个帖子应该早就超过 500 行了吧

@timeship 嗯，成功转移了

全文是 We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. 刚才少引用了最后一句。

跟我之前做 Java 性能优化的体验一致，一个日撑 10 万次请求的服务，我优化到了 30 万，后来 300 万，后来 3000 万。其实没改多少代码，每一步的核心都是找当年的性能瓶颈在哪里。

我们家 CTO 当年优化的一个 iOS 的地图点聚合问题，源代码是苹果 WWDC 的一个 Demo 代码，从全屏 5000 个点，聚合一次需要 22 秒，优化到了几十毫秒，他优化了 7-8 个不同的地方，但是优化的代码量并不大。核心还是找出关键问题。

@holyghost 我没有说你的知识不对的意思。包括 @EagleB 。

高德纳老师有句话叫做“过早优化是万恶之源。”，原文， We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

当你关心了一个明显不是性能攸关的点的时候，我就担心你的大局观了。刚才说了求月日数，一次翻页才调用一次，闰年判断也如此。这根本不是性能攸关点。

其次，一个操作比另外一个操作快，是很常见的。这很正常，但是，按照刚才的 benchmark 在当前测试条件下快了不到一倍。如果本身很耗时，不到一倍也是不错的回报。问题是运行 100 万次都才 7 个 ms ，这快了一倍叫做没有收益。

在实战的性能优化里面，我们关心的第一是运行多次的，性能攸关点。复杂度的增长速度。以及那些差异到了 100-1000 倍，甚至更大的操作。比如内存和硬盘，有了 SSD 没差那么远了，但是仍旧很大。比如硬盘的连续读写和随机读写，比如硬盘，内存和网络。

现在的问题是，卡马克的某个优化很牛逼，某个图形算法里面乘除 2 用位运算（不管是图形算法啦，系统库里面多了去了），这些都没错。

但是人家也不是每句话，都要把乘除 2 改为位运算的。计算机发展的早期，确实有很多这么干的，但是慢慢的都认识到了，有些优化要做，某些最好不做，最好不早做。

@caiyouzai 对的。我以前做搜索， 1 个 ms 都很重要。但是，不是每个代码的 1 个 ms 都要去揪。要找到核心代码，去压榨一点点性能改善，但是调用比较少的，对整体影响不大的，连看都不看。

@holyghost 没错，这是常识，不过我懒得细看你的实现。

我做了一个简单的 benchmark 你可以看看

//
// main.m
// testleapyear
//
// Created by Peiqiang Hao on 2016/11/28.
// Copyright © 2016 年 Peiqiang Hao. All rights reserved.
//

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[]) {
@autoreleasepool {
// insert code here...

NSTimeInterval t1 = [[NSDate date] timeIntervalSince1970];

for (int i = 0; i< 1000000; i++) {

int year = i;
int leapYear = (year & 3) == 0 && ((year % 25) != 0 || (year & 15) == 0);
}
NSTimeInterval t2 = [[NSDate date] timeIntervalSince1970];
NSLog(@"%g",t2-t1);

t1 = [[NSDate date] timeIntervalSince1970];
for (int i = 0; i< 1000000; i++) {

int year = i;
int leapYear = ((year % 4==0 && year % 100!=0) || year % 400==0);
}
t2 = [[NSDate date] timeIntervalSince1970];
NSLog(@"%g",t2-t1);

}
return 0;
}

结果是：

2016-11-28 10:37:54.885253 testleapyear[16140:987950] 0.00339603
2016-11-28 10:37:54.893403 testleapyear[16140:987950] 0.00789499

在 100 万次调用下，你的实现比我快了 4 个毫秒。在我看来，这样的优化，千万不要做，得不偿失。当然如果你觉得我的测试条件写错了，你可以改，我可以再跑一次。运行环境是我的 rmbp 15 寸低配，去年中期的配置。

@juice 续啥费？

@muziki 这个谁要写这个代码在我的项目里面，我要打不及格。

第一，不见得快，这个可以跑一个测试，比如比较 100 万次，试试看，我估计不见得快，或者说不见得有显著的性能收益。
第二，可读性下降。
第三，什么场景需要快速计算闰年，全人类才走了几千年，枚举一边，用最慢的算法，也很快出结果。这么去追求效率得不偿失。

真的不是不能批评，不过，我觉得，做性能优化，我经验比楼主多多了，我就在多少两句吧。关于，那个不用查表，用 Switch-Case 的问题。

这么说话都是半瓶子咣当，性能优化不是教条，不是说，老师说这么写对的就这么写。性能优化是一个一直在变的东西，唯一可以相信的是 profile 。

第一，不要过早优化。
第二，这是一个有限条件选择，不涉及到问题增长速度。
第三，编译器如果觉得这里值得优化成一个 table 会动手的。
第四，性能优化，要理解一个代码调用频度场景。这个函数会被调用几次呢？大概，只在日历初始化的时候，调用一次，翻页的时候，调用一次。翻一次页，人工都设置了一个动画， 0.5 秒，还是多少记不得了。然而，这里用 Switch-Case 还是查表性能差异可能对产品性能产生影响么？

写代码的时候，第一优先是可读性。这个代码其实可读性也一般，因为说过了，基本上就是一晚上随手写的，后来也没改过。性能一定要在 profile 的前提下去做。我们的学校教育，教育出来一堆纸上谈兵的性能知识，很多还是错的。比如很多类似的技巧，在编译器优化前提下，根本不存在了。比如当年谭浩强的书里面给你讲了一堆，在某个编译器可能成成立，在另外一个编译器不能成立的技巧。

我不是说，我这么说一定比查表好。而是，这不是你该关心的问题。如果 profile 说明这里是一个性能攸关点，你做各种尝试都是合理的。在这时候，我觉得想太多。跟讨论回有几个写法差不多。

July 11, 2008 iPhone OS 2.0 Final 发布，同时才有的 App Store 。