Дмитрий Иванов - Сказки о преждевременной оптимизации

[@sergeybenzenko6629]

Я бы сказал, как выразился, если не изменяет память, Акиньшин: "ЭТО ЗАВИСИТ!". Понятно, что в софте реального времени, когда программа должна обработать 100500 файлов после каждого нажатия клавиши пользователем (я утрирую), то производительность на первом месте. Другое дело, что заявленная концепция "разрабатывать СРАЗУ с учётом производительности", как мне показалось, так ни разу и не была представлена. То есть, докладчик рассказал о некоторых случаях использования, к которым они ПРИШЛИ В ИТОГЕ, но я не заметил, чтобы где-то был пример проблемы, когда команда СРАЗУ на этапе проектирования знала, что вот у этого подхода будет плохая производительность, поэтому решили делать вот так, а не иначе. Скорей наоборот, примеры были больше из разряда "мы тут вот это оптимизировали, а тут вот это", что прямо противоречило изначальной мысли. Но даже при всём этом, заявленный тезис касается примерно 0,1% производимого софта, для которого критична производительность. И на такие экстремальные меры 99% программистов в жизни не придётся идти. А подача была, будто бы это обязательно для всех. Это, наверное, единственная претензия. А вообще, примеры очень интересные.

[@dead_earnest]

У меня вопрос - а не может ли в примере на 12 минуте (сравнение сборщиков мусора) быть так, что именно ограничение памяти в 300 МБ является причиной того, что сборщик мусора занимает много рабочего времени?

[@nicklausbrain]

Очень поверхностная лекция. Много пафоса и мало смысла. По принципу Парето 20% кода выполняется 80% времени, и если что-либо нуждается в оптимизации, то только этот код. И поскольку Кнут говорил свою фразу «Преждевременная оптимизация - корень всех зол» в 1974 году, то сейчас, при много большей производительности машин, она имеет ещё большее значение. Правильный код лучше, чем быстрый. Если ты правильно понимаешь требования к приложению, то всегда сможешь выделить функциональность, которая действительно должна быть оптимизирована.

[@GP-ez5ms]

Чушь. В софте наподобие того что пишут ребята из JB, в играх, во всяких фундаментальных софтинах типа СУБД действует правило performance is a feature. Там на него нужно обращать внимание с первого дня и не переставать ни на минуту. То что рассказывает Дмитрий Иванов релевантно именно для их продукта. Если вы пишете очередной репорт билдре, или вебсайт на аспнете, где важно чтобы у юзеров секция "Также с этим товаром покупают" зарелизилась через день после того как ее придумают - так вперед. Рефлексия, линкью, нугет пакеты всех видов вам помогут. В его работе, в моей работе (геймдев), в работе кучи людей у кого перфоманс является фичей слова кнута ничего не значат. Если мы обосрёмся на начальной фазе проектирования, если мы в каждой фиче не будем следить за гребаными аллокациями, профайлить будет нечего. Банальные виртколы в какой то момент начинают мешать. Как вы их увидите в профайлере ? Вы за 10 минут переведете все на структы и статические методы ? Прежде чем коментировать подумайте над тем что хотел сказать автор, и в каком контексте. Если контекст не соответствует вашему - это не проблема докладчика. Это вам нужно перейти на видео где рассказывают как тучей рефлексии уменьшить кол-во кода в контроллерах на пару строк. А мы будем кодегенить, писать бойлерплейт и заниматься прочей неудобной херней чтобы у таких как вы IDE не тормозила, или игра выдавала хороший FPS. kzbin.info/www/bejne/bXi3oaqdqNJ7nbc - вот можете еще и тут написать что парням из Raven надо начать писать правильный код, а то у них неправильный и слишком быстрый.

[@VanyaRelsoUkladchik]

@@GP-ez5ms Какой-то вы очень грубый и категоричный. Дмитрий Иванов экстраполирует ситуацию в своем маленьком болоте на ВСЮ разработку, и пытается кинуть тень на очень уважаемых людей в IT. А что он сам сделал хорошего? Решарпер, который тормозит как хромая улитка? Так что насчёт пафоса - вполне и заслужено. Чуть-чуть уменьшить выпендрёж, добавить доводов и фактов - будет съедобно, а пока - незачёт.

[@AShahabov]

А я что-то не понял, что хотел сказать автор, когда после "Использовать структуры по мере возможности..." в скобках было указано "(ex. List vs IList")? Как List и IList связан со структурами?