Question

注意：我确切知道属性是什么。这个问题与绩效有关。

使用self.fooBar进行READ访问对我来说似乎是浪费时间。不必要的Objective-C消息传递正在进行中。吸气剂通常只是沿着ivar传递，所以只要它确定没有合理的getter方法，我认为绕过这个沉重的家伙是完全可以的。

Objective-C消息传递比直接调用慢约20倍。因此，如果有一些高性能高频代码使用了数百个属性，那么它可能对避免不必要的Objective-c消息传递有很大帮助吗？

还是我在浪费时间思考这个问题？

Answer 1

这种过早的优化应该被推迟，直到你真正注意到或测量（使用Instruments.app）一个真正的问题。

Answer 2

没有冒犯，但你可能在浪费时间思考它。除非您拥有每秒数千次访问该属性的代码，否则您将不会看到任何性能差异。

Answer 3

是使用属性getter比直接访问慢得多。属性getter在自我类（和类别）之外用于封装，但我发现使用self.ivar getter没有任何好处，除非你已经将getter重写为其他内容。

（为什么你首先使用self.ivar？）

self.ivar与self->ivar不同的唯一情况是：

该属性为atomic，so self.ivar will be similar to

spin_lock(&ivar_lock);
id retval = [ivar retain];
spin_unlock(&ivar_lock);
return [retval autorelease];

表示id属性，

spin_lock(&ivar_lock);
spin_lock(&destination_lock);
memcpy(&destination, &ivar, sizeof(ivar));
spin_unlock(&ivar_lock);
spin_unlock(&destination_lock);

表示结构。当属性为nonatomic时，两者之间没有区别。

课程不是最终的。类或子类的类别可以将属性getter重写为其他类。但我认为压倒一个具体的财产并不是一种好的风格。

与其他人所说的一样，除非你测试过吸气剂是一个热点，否则将它改回直接进入ivar将无济于事。

Answer 4

这两者并不是真正可以互换的（好吧有些时候）。当您需要时直接访问ivar，并在需要时使用访问器方法。它可能取决于类层次结构，类的实现，代码线程安全等等。

如果是你的代码，所有事情都在很大程度上取决于你。可能有人想要继承这个类并写一个总是返回@“BOO”的-foobar的自定义实现，但他们发现superClass方法-printFooBar现在打印@“hello darling”因为它打印出变量foobar的值而不是self.foobar返回的值？

调用访问器方法确实比直接使用变量有更多的开销，但还有更多的事情要考虑而不是性能。就个人而言，我发现“总是使用存取方法”这个位置就像说“从不使用存取方法”一样荒谬 - 这显然是荒谬的。

Answer 5

有些人可能不同意，但我碰巧喜欢直接访问ivar并尽可能绕过整个消息传递业务。我认为这使我的意图更加清晰，因为如果我需要发信息（用于内存管理等），那么我会。

Answer 6

它的效率稍微低一点，但你通常不应该让你的对象状态公开。虽然公共成员在大多数OO语言中被认为是不好的，但实际上在Objective-C中有一个实用的原因：框架使用你的“getter”和“setter”方法来自动化某些事情，例如内存管理和KVO通知。通过从多个地方访问的ivars，每个客户端代码都需要完全理解访问者方法所承担的所有责任，并以完全相同的方式执行这些职责。

所以不是“绝对不能访问你自己的ivars”，而只是确保你完全理解它在特定情况下的含义。

如果我使用self.fooBar而不是fooBar，它会对性能产生影响吗？

6 个答案: