注意:您的示例程序是一个微型基准测试程序,非常有效地最大限度地放大了日期格式化程序的成本。您正在比较做什么都不做与做点事。因此,无论是什么东西是,它将显示为东西时间慢于没有。
这样的测试非常有价值且极具误导性。微型基准通常只在您有真实世界的Teh Slow情况下才有用。如果您要将此基准测试速度提高10倍(实际上,您可能可以使用以下建议),但真实世界的情况只占应用程序总体CPU时间的1%,最终结果不会是戏剧性的速度提升 - 它几乎不会引人注目。
这样的成本是什么原因?
NSDateFormatter* dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"yyyyMMdd HH:mm:ss.SSS"];
最有可能的,成本既不必解析/验证日期格式字符串和做任何一种特定的语言环境是粘性物质从中确实NSDateFormatter
相关。可可对本地化提供了非常全面的支持,但这种支持的代价是复杂性。
看你如何编写一个相当不错的示例程序,你可以在仪器中启动你的应用程序,并尝试各种CPU采样仪器,以了解什么是消耗CPU周期以及仪器是如何工作的(如果你发现有趣的事情,请更新您的问题!)。
有没有线程必须等待对方的阻塞?
我很惊讶,它不会简单地崩溃,当你从多个线程使用单个格式化程序。 NSDateFormatter
没有具体提及它是线程安全的。因此,你必须假设它不是线程安全的。
如何提高使用率?
不要创建如此多的日期格式化程序!
要么保留一个操作的批处理,然后摆脱它,或者,如果您始终使用'em,请在应用程序运行的开始时创建一个并保留,直到格式更改。
对于线程,每个线程保持一个,如果你确实需要(我敢打赌这太过分了 - 你的应用程序的体系结构是这样的,每批操作创建一个会更明智)。
,我愿意给你三个点为基准的应用程序,如果我能。那么2,因为iVars都带有'm_'前缀,但是......仍然是一个很好的起点,可以深入深入w /仪器,采样,线程等...... – bbum 2010-12-14 18:13:17