|
|
51CTO旗下网站
|
|
移动端

千禧危机

《iOS和macOS性能优化:Cocoa、Cocoa Touch、Objective-C和Swift》第7章内存:陷阱和优化技巧,本章将围绕这个话题来进行讨论。除此之外,我们将展示一些陷阱,尤其是在Objective-C 代码中经常出现的问题。本节为大家介绍千禧危机。

作者:李俊阳 等译来源:电子工业出版社|2018-07-17 16:56

千禧危机

那一天,人类终于回想起了,2000 年(千禧年,Y2K)来临之时所带来的恐惧,这是因为许多程序只是用了2 位数来表示日期,比如说1982 年用字符串82 来表示,其默认前面隐含了19 这个前缀。这显然会在千禧年降临之日导致软件停止工作,因为程序会将当日理解为1900 年的第一日,从而导致计算速度异常等错误。

虽然以前的开发人员会假定,他们的程序会在出现问题之前就被替换掉,然而出乎意料的是这些有问题的软件却比预期长寿得多,这导致全世界花费了数十亿美元来为这个错误买单,还有各种跨年日的彻夜加班,幸运的是损失并不算太大。所以,在这里所提的建议是否可能有类似的缺陷呢?

我觉得答案是“没有”。首先,我们的建议是对对象中的阈值范围进行优化,我试图在封装边界条件之内让其运行更为迅速,而不是简单地优化了事。对于消息接口而言(参数和返回值),我们通常建议使用机器的全宽字长(即32 位或者64 位的整数,以及相应的float/double 浮点数),这几乎不会导致性能损耗,因为它们可以将整个寄存器填充满。其次,即便这里对表征方式做了一点微小的优化,但是日期的表示范围仍然还有巨大的空间。因此,即便我们的软件还需要运行几十亿年,或者人类对色彩的敏感度进化了几十亿倍,也只需执行一个本地化组件的小更新即可,其他的接口完全可以保持不变。

喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

Visual Studio 2005+SQL Server 2005数据库应用系

本书主要介绍采用Visual Studio 2005的C#语言为前台,SQL Server 2005数据库为后台的数据库系统开发技术。 全书分为15章,内容包括走进.NE...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊