> что во многих местах длинными цепочками вызывалась куча
> геттеров. Примерно так:
> getA.getB.getC...getX.getY.getZ
> Причем из кода было ясно, что между такими вызовами значение
> Z не меняется - то есть, результат этой цепочки всегда будет
> один и тот же.
...
> Что и сделал, потратив совсем немного времени. Результат
> почти  ошеломил - скорость тут же выросла примерно в 50
> раз и была признана достаточной.

Большое спасибо вам за конкретный пример.
На самом деле речь всегда именно про это (для меня).
"Зачем вот тут вызываешь функцию 28 раз? зачем вот тут навтыкал проверки одних и тех же параметров во всех 100 методах?"
"Ты занимаешься преждевременной оптимизацией, а кнут (едрит его налево!) сказал..."

Спасибо, что внесли конкретику.

От того я на этого кнута и зол, ибо, по-моему, фигню он сморозил.

Единственное, в отличии от вас я не переделывал код для проверки реального влияния, но должна же быть разумность при написании кода, епты!

> Зачем вот тут вызываешь функцию 28 раз

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

> навтыкал проверки одних и тех же параметров во всех 100 методах

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

Причем, тормоза в функции и/или в отдельном методе проверки параметров - это уже тормоза сосредоточенные, а не размазанные.

> KSergey ©   (11.11.16 11:06) [20]

Попробуйте программу погонять под указанным мною SampleProfile'ом или его аналогом. Результат может удивить.
Хотя, конечно, статическую оптимизацию никто не отменял - и без выполнения программы можно найти много полезного.

Без правильной архитектуры приложения заниматься оптимизацией бессмысленно.
Но, если архитектура выстроена ровно - заниматься оптимизацией в 95 процентов случаев даже не придется.

> Rouse_ ©   (11.11.16 12:03) [23]

Правильная архитектура, это как правильное решение - не всегда сразу понятно, насколько оно правильное.

Юрий Зотов ©   (11.11.16 10:38) [19]

"Обращало на себя внимание то, что во многих местах длинными цепочками вызывалась куча геттеров. Примерно так:
getA.getB.getC...getX.getY.getZ
Причем из кода было ясно, что между такими вызовами значение Z не меняется - то есть, результат этой цепочки всегда будет один и тот же.
...
Что и сделал, потратив совсем немного времени. Результат почти  ошеломил - скорость тут же выросла примерно в 50 раз и была признана достаточной.
"

"Аналогичный случай" (С). Ошеломлен не был потому, что подозревал после просмотра результатов в профайлере, но все же был удивлен. :-)
С тех пор на автомате везде так пишу. Цена, обычно - это объявление одной переменной.
Впрочем, я подобные вещи преждевременной оптимизацией не считаю.

не нужно понимать буквально

> "Преждевременная оптимизация — корень всех зол"

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

> Внук ©   (11.11.16 13:01) [27]

> Какие же вы суперзадачи решаете, если на современных компьютерах
> имеет проблемы с быстродействием. Завидую.

Например, массовый перерасчет выплат всем пенсионерам в регионе (скажем, в Москве).

Тут не завидовать надо, скорее - сочувствовать.
:o)

> Юрий Зотов ©   (11.11.16 13:15) [28]

Я так и подозревал, что все проблемы от пенсионеров :)

> Внук ©   (11.11.16 13:01) [27]

Испортить можно все, что угодно. Современный компьютер исключением не является :)

> DayGaykin ©   (11.11.16 12:13) [24]
>
> > Rouse_ ©   (11.11.16 12:03) [23]
>
> Правильная архитектура, это как правильное решение - не
> всегда сразу понятно, насколько оно правильное.

Ты вспомни как я ГСИ писал, почти месяц ни одной строчки кода - сидел только схемы рисовал.
А результат - в багтрекере ошибок всего 8 процентов от общей лавины.
Оть так-то. И оптимизацию только в узком месте делал - там где FTS первого уровня зачитывался с диска.

Писала программу. Решала в лоб. Кучей if, case и т.д. Оптимизировать время не было.
Программа делала то, что надо, за полторы минуты.
На замечания, что программа не оптимизирована плевала. работает же. И довольно быстро.
Оптимизация нужна не везде, не всегда и не всем.

ИМХО! очень, очень ИМХО!

> manaka ©   (12.11.16 12:30) [32]

У нас на работе программист:
- Страница открывается 70 секунд - это нормально и быстро ещё.

А чтобы выполнить работу, сотрудникам необходимо открыть страницу 120 раз в день (в пиковые дни). Т. е. два часа сотрудники просто ждут. Это же ужасно.

> Rouse_ ©   (11.11.16 14:05) [31]

Я больше запомнил твой метод принятия правильных решений: Принимаешь решение и считаешь его правильным.

> DayGaykin ©   (12.11.16 13:03) [34]
>
> > Rouse_ ©   (11.11.16 14:05) [31]
>
> Я больше запомнил твой метод принятия правильных решений:
>  Принимаешь решение и считаешь его правильным.

Я разве хоть раз ошибся? :)

> Страница открывается 70 секунд - это нормально и быстро
> ещё.

Знакомо )
Иногда разработчики сидят на порезанных и фейковых данных, пишут запросы, у них все летает - таблички на пару тысяч строк.  Деплоим - по минуте висит. И начинаем искать куда и какой индекс залепить.

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

Как писали Миллсап с Хольтом, оптимизировать надо важные для бизнеса операции, а не все подряд гайки крутить, только потому, что они крутятся.

2 Игорь Шевченко ©   (12.11.16 21:43) [37]
Ну при чём тут количество строк, Игорь?
В каких-то случаях оптимизация нужна и в десятке/сотне строк.
Если они выполняются в некоем цикле.

> метод принятия правильных решений:
>  Принимаешь решение и считаешь его правильным.
!
а как иначе - вначале принял, а потом считаешь не правильным, а зачем тогда принимал?  ;)