> NoUser ©   (13.11.16 02:23) [39]

Не сразу дошло:)

> Игорь Шевченко ©   (12.11.16 21:43) [37]
> Хуже, когда разработчики начинают оптимизировать то, где
> больше пары тысяч строк не может быть в принципе.
>
> Как писали Миллсап с Хольтом, оптимизировать надо важные
> для бизнеса операции, а не все подряд гайки крутить, только
> потому, что они крутятся.

Во-во, только не все это понимают.
Я Пете Абрамову однажды писал проект (сервис + конфигуратор) он передал его заказчику а там местный "кодер" решил сервис поправить, все поломал.
Вызывают, приезжаю, смотрю код - волосы дыбом
- ты зачем сюда вообще полез? Ты сервисы то писать вообще умеешь, спрашиваю?
Отвечает - ну я заоптимизировать хотел как лучше. И отладочные из сервиса через Writeln выводит - ппц.

Во вспомнил, даже кусок этого модуля откопал.
Там ситуация была что Петя просил сделать маленький и шустрый сервис - я все на API накатал, а этот чудик (кодер) увидел что синхронизация нитей делается не по феншую, т.е. без вызова TThrad.Synchronize() ну и отцепил мою синхронизацию через SendMessage в нить сервиса, переписав на Synchronize. А т.к. TService не использовался, Synchronize пыталась влезть в основную нить приложения, которая предназначена для работы с SCM и висит в суспенде 99.9 десятых процентов времени, причем для лога встроил
Wrinteln('Начало синхронизации');

Это была феерия :)

> Rouse_ ©   (13.11.16 11:48) [42]


Саш, я старался тестовый пример в после 14 писал, а никакой реакции)))

Скажи, вот ты стараешься избегать SEH как в моем примере?

> Тимохов Дима ©   (15.11.16 03:02) [43]
> Скажи, вот ты стараешься избегать SEH как в моем примере?

У меня нет больших циклов, поэтому нечего оптимизировать.

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


У меня с покером много вычислительных задач требуют время. Например, построить конечный автомат, который бы по пяти картам выдавал силу руки. По семи картам. Потом проверка того, что для всех раскладов перестановка карт не меняет силу руки. И т. д. и т. п.

> Внук ©   (11.11.16 13:01) [27]
> Какие же вы суперзадачи решаете, если на современных компьютерах
> имеет проблемы с быстродействием. Завидую.

Приходите к нам.
Толковые разработчики нужны всегда.

Суть в том, что из текущих состояний дел в мире и ориентиров надо успевать обсчитывать несколько десятков тысяч операций в секунду, это будет соответствовать ожиданиям клиентов.
А у нас каждая операция рассчитывается 1..2 мс, что, понятно, как минимум на порядок хуже. И при этом количество бизнес правил, которые надо проверять и учитывать, растёт. Такая вот фигня.

Понятно, что "менять архитектуру" и прочие красивые слова - прикольно, но это отдельная история.

Пока же меня лично беспокоит, что при написании нового кода то, что всё уже работает не быстро - вообще забывается. Т.е. абсолютно не учитывается почему-то.

> Толковые разработчики нужны всегда.


Не надо сманивать толковых разработчиков :)

Если учитывать, когда на компьютерах начали моделировать ядерные взрывы и решать другие сложные задачи, сравнить быстродействие тех и современных компьютеров, то говорить о нехватке быстродействия для бизнес-поделок, это из серии "слишком много кушать, в смысле - зажрались", нет?
Понятно, что бизнес захочет получать всю в мире аналитику за секунду по нажатию кнопки. Только если говорить правду, выяснится, что не так уж это и надо, и не совсем уж за секунду, и вообще на перекуры больше времени уходит.

А есть например еще современные игрушки с фотореалистичной графикой. Там требования к ресурсам ого-го :)

> Внук ©   (16.11.16 10:51) [48]
> Если учитывать, когда на компьютерах начали моделировать ядерные взрывы и решать другие сложные задачи, сравнить
> быстродействие тех и современных компьютеров, то говорить о нехватке быстродействия для бизнес-поделок, это из серии
> "слишком много кушать, в смысле - зажрались", нет?

На самом деле я вашу позицию полностью понимаю.
Однако позволю себе разъяснить и другую позицию.

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

Ну и потом, как верно говорит начальник "главное в этой цепочке не быть самым медленным". Так что приходится не отставать от индустрии, и так по спирали каждый её участник, а что делать. Иначе деньги уйдут к другому. И тогда уже встанет вопрос "а что бы кушать мне", чего мне бы не хотелось, признаться.
Когда-то и конвейеры были не нужны. Или нужны, но "а зачем?".

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

> Внук ©   (16.11.16 10:51) [48]


> моделировать ядерные взрывы

моделирование моделированию рознь )

Про конкуренцию, это я понимаю.

Зато вспомнился случай из жизни, когда мы переводили нашу программу с MS-DOS на Windows, тогда только начала распространяться Win95, а компьютеры конечно были не самые свежие, но на которых DOS-овские программы вполне себе работали с хорошей скоростью
Тогда нам несколько месяцев начальство выносило мозг на предмет того, почему запуск новой версии программы так ужасно медленно происходит по сравнению со старым досовским аналогом.
Поскольку вопрос о том, чтобы НЕ переходит по Win, не стоял, оставалось только молча разводить руками и отводить душу в курилке :)

Мораль - хотите рюшечки, обеспечьте должное железо.

> запуск новой версии

Под запуском новой версии я имею в виду, конечно, время старта программы от момента щелканья по ярлыку до реакции на пользовательский ввод, а не время подготовки нового релиза.

> время старта программы
ну так наверное все формы в автозагрузке, а там всякие конекшены в тру ))

> Внук ©   (16.11.16 15:51) [52]
> Мораль - хотите рюшечки, обеспечьте должное железо.

В данном случае - увы, не поможет.
В том смысле, что железо у клиентов в прямом смысле самое топовое, какое только можно купить в каждый конкретный момент на мировом рынке. Ну в рамках платформы, как она раньше называлась, IBM PC.
(как называется сейчас, интересно?)

> ухты_х ©   (16.11.16 16:44) [54]

Это был, наверное, 1996 или 97-ой год, и программа была на C++ :)

https://habrahabr.ru/company/jugru/blog/316854/
> оптимизация – это постоянный и длительный процесс.