Оптимизация: доступ к полям и методам - PullRequest
3 голосов
/ 01 ноября 2010

Я знаю правило № 1 оптимизации: не делай этого!Но я подумал, что это простой вопрос, и если я начну использовать более быстрый метод, я смогу сэкономить много времени процессора, когда я закончу.

Я делаю RPG, и скажем, что эточасть пользовательского класса:

public class Baddie{

    int health;
    int magic;

    public Baddie(int health, int magic){
        this.health = health;
        this.magic = magic;
    }

    public int getHealth(){
        return health;
    }

Теперь, ответ на мой вопрос может быть "нет разницы", и это нормально для меня ... Я просто хочу знать.Быстрее ли получить здоровье Злодея, используя полевой доступ:

//Somewhere in the main thread, I get an instance of Baddie..
Baddie b = getScaryBadGuy();
int baddieHealth = b.health;

Или быстрее использовать метод возврата?

int baddieHealth = b.getHealth();

Ответы [ 4 ]

5 голосов
/ 01 ноября 2010

Скопировано и вставлено из Проектирование для производительности :

Избегайте внутренних геттеров / сеттеров

Inна родных языках, таких как C ++, обычной практикой является использование методов получения (например, i = getCount ()) вместо прямого доступа к полю (i = mCount).Это отличная привычка для C ++, потому что компилятор обычно может встроить доступ, и если вам нужно ограничить или отладить доступ к полю, вы можете добавить код в любое время.

В Android это плохая идея,Вызовы виртуальных методов стоят дорого, намного больше, чем поиск полей экземпляра.Разумно следовать общепринятым методам объектно-ориентированного программирования и иметь методы получения и установки в открытом интерфейсе, но внутри класса вы всегда должны обращаться к полям напрямую.

Без JIT прямой доступ к полям примерно в 3 раза быстрее, чем вызовтривиальный добытчик.С JIT (где прямой доступ к полю обходится дешевле, чем доступ к локальному), прямой доступ к полю примерно в 7 раз быстрее, чем вызов тривиального геттера.Это верно для Froyo, но улучшится в будущем, когда JIT встроит методы получения.

1 голос
/ 01 ноября 2010

Производительность всегда относительна. Обычно лучше думать в процентах или факторах. Если что-то занимает микросекунду, может это много, а может и ничего. Это зависит от того, сколько раз в секунду вам нужно это сделать. Это главная причина, по которой преждевременная оптимизация осуждается, она выполняется без ведома, если есть проблема.

0 голосов
/ 01 ноября 2010

IMO, это скорее вопрос дизайна, чем вопрос оптимизации.Я бы посоветовал не писать / генерировать какие-либо методы получения или установки, пока вам действительно не понадобится доступ к ним извне вашего класса.Это имеет тенденцию сохранять связь как можно более низкой.

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

0 голосов
/ 01 ноября 2010

Компилятор оптимизирует, если может. Это прекрасный пример преждевременной оптимизации. используйте все, что имеет смысл в вашем коде. Не беспокойтесь о «сохранении циклов». 2-3 цикла, которые это может или не могут сохранить, перевешиваются миллионами циклов, которые требуются для любой другой операции.

...