Народ.

Захотелось узнать разницу в скорости различных реализаций одного и тог же.
Я понимаю, что работа с паблик полями на прямую должна быстрее работать, чем через сеттеры\геттеры. Однако повальное исполнение правила всех програм-эталонов делать доступ через методы побудило меня сравнить 2 подхода, мало ли как там машина устроена. И оказалось, что вызов геттер\сеттера работает раза в 2-2.5 медленнее чем прямой доступ. Значит в некоторых случаях как раз нужно делать доступ прямым.
Порылся немного в инете и к своему удивлению обнаружил, что самые быстрые - это статик методы.

Народ, дайте ссылки на соответствующие темы. Я нашёл крайне мало информации на русском.
Меня интересует во первых что из возможных вариантов работает быстрее, и во сколько раз. Меня интересует какой вариант сколько условных ресурсов жрёт.

1) Вызов метода класса, метода абстрактного класса, интерфейса
2) сколько жрёт операция приведения типов, стоит ли делать поле OBJECT универсальным, если известно, что оно будет конкретного типа
3) Сравнение статик методов, финал, паблик, приват методов
4) Рекурсия и  итераторный способ прохода
5) Вызов функции (можно пустой) от кол-ва её параметров, и возвращаемого типа

У кого есть данные тестов приводите, буду благодарен

Добавлено через 44 секунды
Если есть какие-нибудь советы по оптимизации, пишите.

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

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

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

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

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

Даже если я и не буду активно использовать эту информацию, нормальному прогеру её владеть хотябы теоретически надо.

Код в первую очередь должен быть ЧИТАБЕЛЬНЫМ, т.к. неизвестно кому прийдется его после Вас дорабатывать\исправлять.

Знал я такого оптимизатора одного, конвеншены не соблюдал, названия переменных прыгали как хотели, задачи которые занимают по 50 и больше миллисекунд запускал из конструктора.

Ну а замена instanceof на булены в сложной иерархии классов - вообще вершина маразма.

В результате после него осталась куча не читабельного кода, который работает не так как должен. И теперь уже стоит вопрос - а стоит ли разбираться в таком бреде или просто написать все заново? А работы там на пару недель...



По теме оптимизации:

Была у меня программка... Конвертировала из одного формата данные в другой. Изначально потребляла 450+ мб памяти и выполнялась почти две минуты.

После плясок с бубном (убрал лишние создание обьектов, заменил данные на примитивы, написал утилиты которые вытаскивали из примитивов нужные данные) она начала использовать 160 мб памяти и работать 28 сек.

Мораль? Проблема была не в геттерах\сеттерах, а в не оптимальной структуре хранения данных.
Да и в подавляющем большинстве случаев корень зла кроется именно в не оптимальном алгоритме работы, т.к. при серьезной нагрузке (базы данных, клиент-сервер, прочее) выигрыш составит около1-2% в лучшем случае. Стоит ли из-за этого выигрыша делать код нечитабельным и сложным в понимании, где, вполне возможно, что выигрыш от такой оптимизации за ближайшую сотню лет будет меньше чем программист потратит времени на эту самую оптимизацию?

P.S. Вы не пробували писать весь код без переводов строк и пробелов? Говорят исходники занимают меньше места   

+1

От себя добавляю, что темой оптимизации заниается сама JVM, это в первых версиях был "простенький" интерпретатор, сейчас же она много чего стала уметь, - как например преобразование каких-то методов в статик. Сейчас ОЧЕНЬ многое оптимизируется JVM-ом на лету.

Хорошо, пробуем по другом.

Есть самопальное дерево. Примерно состоит из 100...00 единиц узлов.
Сделал рекуррентный проход по дереву где метод рекурсии был методом дерева.

Я попробовал по другому, сделал метод рекурсии методом Узла. Разница оказалась 15%. И это эффективная разница, т.е. кроме рекурсии в методе ещё и операции были.

Оно конечно и понятно, что быстрее. 

Для того, чтобы понять нужна ли оптимизация, нужно знать сколько она может дать, т.е. нужны данные, которые я хочу от вас получить.
Если замена типа метода даст выигрыш 15-20 процентов - это одно, а если 1% - это другое.

Заранее исключаю просчеты в общем алгоритме. Со стратегией все хорошо, мне нужна тактика.

Lisius, выигрыш будет заметно меньше чем от оптимизации аллгоритма...



Это сообщение отредактировал(а) SoulKeeper - 19.8.2008, 17:58

Я правда примерно об этом уже говорил, но повторюсь: HotSpot из вот такого куска кода:



сделает в рантайме примерно вот это: