Оптимизация: доступ к полям против методов

Я знаю правило №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(); 

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

    Избегайте внутренних Getters / Setters

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

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

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

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

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

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

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

    Intereting Posts
    Интеграция ACRA и Google Drive Как избежать ожидания в основном потоке при добавлении заголовков в запросы с использованием модификации? Android Multidex RuntimeException RecyclerView не обновляется после NotifyDataSetChanged (), содержимое отображается после включения и выключения экрана. Разница между cocos2d-android и cocos2d-android-1 Используйте простую безопасную пару Jelly Bean (Bluetooth) для сопряжения с NFC Android Float To Int Какой SDK для платформы Android мне нужен? Получить доступ root через su в эмуляторе Android Как изменить цвет фона выбранных элементов в ListView? Эффекты перехода активности: слайд для верхней активности и масштаба для нижней активности Улучшение производительности OpenCV Android – быстрое отслеживание объектов Как получить все имена файлов внутри папки в папке с ресурсами в Android? ADB не работает и не смог инициализировать ошибку потока монитора, возникающую в ddms в android Как отправить файл cookie вместе с HttpGet в Java