objective-c - Profiler 告诉我与 nil 的比较很慢

Question

我有一个方法可以检查 aNSData的值，如下所示：

if (data == nil) {

//Method

}

但是，尽管方法中包含了所有内容，但事实证明，超过 80% 的时间都花在了第一行，检查是否data等于nil. 有没有更有效的方法来做到这一点？

截屏：在此处输入图像描述

score 3 · Accepted Answer

这不是直接比较nil。它是一行中的多个语句。

划分问题的一种方法是划分陈述。您还可以单步执行您的实现。简而言之，分析器的突出显示被误解了。

打破这个：

NSData * thumbnailData = self.thumbnail;
NSUInteger length = thumbnailData.length;

访问属性不需要太多时间。

访问长度应该不会花费太多时间（假设这是不可变数据）。

我怀疑在self.thumbnail. 但是，如果您深入了解实现，分析器将为您提供更多详细信息。

最后一点是，它可以被解释为方法的本地。如果该方法不是热点并且上述方法确实不起作用，那通常意味着“通常在您调用此方法时加载缩略图”。

score 1 · Accepted Answer

肯定没有比直接比较更快的检查方法了nil，或者至少你不会通过摆弄那条线来获得任何显着的性能——这个分析数据是不准确的。

-getThumbnail以我的经验，当方法（在您的情况下）运行太多次时，会发生这种行为（仪器错误地“指责”方法的第一行）。尝试优化何时-getThumbnail被调用。

score 1 · Accepted Answer

您必须考虑经典的采样型性能分析器是如何工作的。

基本上，当您的程序运行时，计时器会每隔 100 微秒关闭一次，然后您的程序就会被中断。分析器然后检查指令指针，并根据其相对于被分析代码段的开始和结束的值，索引到整数计数器数组并递增对应于代码地址的计数器。

但是（至少）有三件事阻止了它“完美”：

除了非常小的程序，为每条指令设置一个计数器是不切实际的，因此代码空间被分割成 16 字节或 1000 字节的间隔，具体取决于您的设置方式，并且单个计数器收集增量对于该范围内的所有指令。这意味着关于您在程序中的确切位置的测量“精度”并不完美。
这在很大程度上取决于特定的处理器，但通常处理器仅在代码中的某些点识别计时器中断，例如分支和执行某些“系统”操作时，或者它可能只是等到预取缓存耗尽。因此分析器的定时器中断可能会“触发”，处理器可能会继续执行更多指令。
某些代码序列（例如比较和交换）可能会禁用中断，因此禁用区域内的所有活动最终都将“归咎于”紧随其后的指令。类似地，某些类型的系统调用是以在调用期间禁用中断的方式进行的，因此，调用的全部成本再次“归咎于”紧随其后的指令。

3 回答 3