Имеет ли это значение в производительности, если я использую self.fooBar вместо fooBar? - PullRequest
3 голосов
/ 26 мая 2010

Примечание: я точно знаю, что такое недвижимость. Этот вопрос о производительности.

Использование self.fooBar для доступа READ для меня кажется пустой тратой времени. Ненужные сообщения Objective C продолжаются. Геттеры, как правило, просто проходят по ивару, так что, если он уверен, что не будет написан разумный метод получения, я думаю, что это прекрасно, обойти этого тяжелого парня.

Обмен сообщениями в Objective-C примерно в 20 раз медленнее, чем прямые звонки. Так что, если есть какой-нибудь высокопроизводительный высокочастотный код с сотнями используемых свойств, может быть, это очень поможет избежать ненужных сообщений Objective-C?

Или я трачу время на размышления об этом?

Ответы [ 6 ]

8 голосов
/ 26 мая 2010

Этот вид преждевременной оптимизации действительно следует отложить до тех пор, пока вы действительно не заметите или не измерите (с помощью Instruments.app) реальную проблему.

2 голосов
/ 26 мая 2010

Они на самом деле не взаимозаменяемы (в некоторых случаях это нормально). Получите доступ к ivar напрямую, когда это то, что вам нужно, и используйте методы доступа, когда это то, что вам нужно. Вероятно, это будет зависеть от иерархии классов, реализации класса, безопасности потока кода и т. Д. И т. Д.

Все, что в значительной степени зависит от вас, если это ваш код. Возможно, кто-то захочет создать подкласс этого класса и написать пользовательскую реализацию -foobar, которая всегда возвращала @ "BOO", но они обнаружили, что метод superClass -printFooBar теперь печатает @ "hello darling", потому что он выводит значение переменной foobar вместо значение, возвращаемое из self.foobar?

Вызов метода доступа имеет больше накладных расходов, чем непосредственное использование переменной, но нужно учитывать больше вещей, чем производительность. Лично я нахожу позицию «всегда использовать метод доступа» такой же нелепой, как высказывание «никогда не использовать методы доступа» - что, безусловно, было бы нелепо.

2 голосов
/ 26 мая 2010

Да, использование методов получения свойств намного медленнее, чем прямой доступ. Получатель свойства полезен вне класса self (и категорий) для инкапсуляции, но я не вижу никаких преимуществ при использовании получателя self.ivar, если вы не переопределили получатель для чего-то другого.

(И почему вы вообще используете self.ivar?)

Единственные случаи, когда self.ivar будет отличаться от self->ivar:

  1. Свойство atomic, , поэтому self.ivar будет похоже на

    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.

  2. Когда урок не окончательный. Категория класса или подкласса может переопределить свойство get к чему-то другому. Но я думаю, что переопределение конкретного свойства не очень хороший стиль.

Как и то, что говорили другие, если только вы не проверили, что геттер - это горячая точка, переключение обратно на прямой доступ к ивару не сильно поможет.

2 голосов
/ 26 мая 2010

Без обид, но вы, вероятно, тратите время на размышления об этом. Если у вас нет кода, который обращается к этому свойству тысячи раз в секунду, вы не увидите никаких различий в производительности.

1 голос
/ 26 мая 2010

Некоторые могут не согласиться, но мне нравится получать прямой доступ к ивару и обходить всю систему обмена сообщениями, где это возможно. Я думаю, что это проясняет мои намерения, так как, если мне когда-нибудь понадобится отправить сообщение получателю (для управления памятью и т.п.), тогда я сделаю это.

0 голосов
/ 26 мая 2010

Это немного менее эффективно, но вы все равно не должны делать ваш объект общедоступным. Хотя публичные члены считаются плохими в большинстве языков OO, на самом деле есть прагматическая причина, почему в Objective-C: платформа использует ваши методы «getter» и «setter», чтобы автоматизировать определенные вещи, такие как управление памятью и уведомления KVO. При доступе к ivars из нескольких мест каждый фрагмент клиентского кода должен полностью понимать все обязанности, которые брали методы доступа, и выполнять эти обязанности точно таким же образом.

Так что это не «абсолютно не получайте доступ к своим собственным иварам», а просто убедитесь, что вы полностью понимаете, что это влечет за собой в данной ситуации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...