V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  tinyfool  ›  全部回复第 2 页 / 共 5 页
回复总数  83
1  2  3  4  5  
@hoosin
2020-01-08 09:26:05 +08:00
回复了 cavendish0 创建的主题 程序员 技术大神的中年危机:工作× 肚子✔
@cirton 加油
@qwingmix 回归谈不上,以前来的也不多,也没有说再也不来啥的
@LokiSharp 很久不上了,今天被骂了,就上来看看
2020-01-07 18:36:47 +08:00
回复了 cavendish0 创建的主题 程序员 技术大神的中年危机:工作× 肚子✔
@Epsil0n9 en,大家一起加油就是了。我现在早就看淡了
2020-01-07 17:32:39 +08:00
回复了 cavendish0 创建的主题 程序员 技术大神的中年危机:工作× 肚子✔
@Epsil0n9 没事儿,谢谢
2020-01-07 16:06:59 +08:00
回复了 cavendish0 创建的主题 程序员 技术大神的中年危机:工作× 肚子✔
@mazai 谢谢
2020-01-07 15:50:53 +08:00
回复了 cavendish0 创建的主题 程序员 技术大神的中年危机:工作× 肚子✔
欢迎看完再喷…居然被转了过来
2016-11-28 15:25:57 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
@isaced 嗯,这个代码才 500 行,目前这个帖子应该早就超过 500 行了吧
2016-11-28 15:03:12 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
@timeship 嗯,成功转移了
2016-11-28 11:19:37 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
全文是 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 个不同的地方,但是优化的代码量并不大。核心还是找出关键问题。
2016-11-28 11:07:05 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
@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 改为位运算的。计算机发展的早期,确实有很多这么干的,但是慢慢的都认识到了,有些优化要做,某些最好不做,最好不早做。
2016-11-28 10:50:21 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
@caiyouzai 对的。我以前做搜索, 1 个 ms 都很重要。但是,不是每个代码的 1 个 ms 都要去揪。要找到核心代码,去压榨一点点性能改善,但是调用比较少的,对整体影响不大的,连看都不看。
2016-11-28 10:41:22 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
@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 寸低配,去年中期的配置。
2016-11-28 10:21:13 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
@juice 续啥费?
2016-11-28 10:13:47 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
@muziki 这个谁要写这个代码在我的项目里面,我要打不及格。

第一,不见得快,这个可以跑一个测试,比如比较 100 万次,试试看,我估计不见得快,或者说不见得有显著的性能收益。
第二,可读性下降。
第三,什么场景需要快速计算闰年,全人类才走了几千年,枚举一边,用最慢的算法,也很快出结果。这么去追求效率得不偿失。
2016-11-28 09:40:00 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
真的不是不能批评,不过,我觉得,做性能优化,我经验比楼主多多了,我就在多少两句吧。关于,那个不用查表,用 Switch-Case 的问题。

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

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

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

我不是说,我这么说一定比查表好。而是,这不是你该关心的问题。如果 profile 说明这里是一个性能攸关点,你做各种尝试都是合理的。在这时候,我觉得想太多。跟讨论回有几个写法差不多。
2016-11-27 21:14:03 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
July 11, 2008 iPhone OS 2.0 Final 发布,同时才有的 App Store 。
2016-11-27 21:03:50 +08:00
回复了 EagleB 创建的主题 程序员 看了眼 tinyfool 经常提的日历控件
我一直懒得开源,我们实现的 iBookAuthor 解析器和 Cocoa touch Android 版,不过回头等我懒癌结束了,欢迎你们去看你,不过请不要揪着代码风格。看看内容,看看具体实现,看看架构,那两个东西蛮好玩的。

前者还好。后者光把环境搭起来,编译好全部的依赖可能就需要一个小时。

要是真有天我们开了,欢迎去研究研究。


另外,我最近扒了一个 Google 的库,改造成了 Cocoa 的接口,拖延症不加剧的话,也许 1-2 个月会开源,到时候有兴趣可以看看。
1  2  3  4  5  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1399 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 14ms · UTC 23:42 · PVG 07:42 · LAX 15:42 · JFK 18:42
Developed with CodeLauncher
♥ Do have faith in what you're doing.