Когда вы думаете о разработке любого .NET приложения до недавних пор можно было себе позволить считать, что приложение, которое вы делаете, будет всегда работать на одной и той же платформе: это операционная система Windows, запущенная поверх технологического стека Intel. Сейчас же с каждым прожитым днем мы входим в новую эпоху: платформа .NET стала поистине кроссплатформенной, пустив новые корни в сторону всех доступных настольных операционных систем. Это -- прекрасное время и наш долг сейчас не потерять нить и остаться востребованными специалистами. Ведь когда toolset становится кроссплатформенным, это означает что мы обязаны начать смотреть внутрь. Изучать, как работает двигатель нашей платформы. Чтобы понимать, почему тот ведет себя, так или иначе, на различных системах.
Вторая мысль, которую мне хотелось бы передать через страницы данной книги: даже если ваши сервера будут сверхпроизводительными. Даже если они будут настолько быстрыми, что будет казаться, что оптимизации -- последнее дело, о котором стоит думать... Вы всё равно начнёте оптимизировать код. Вспомните: когда-то всем известный системный программист Билл Гейтс сказал, что 640 Кб памяти должно хватить любому. И на тот момент это было правдой. И на тот момент если скажи любому, что через каких-то 20 лет один компьютер сможет заменить несколько тысяч серверов того времени, вам бы сказали: в ваше время производительность настолько высокая, что над оптимизацией наверняка не стоит даже задумываться. Но что же мы видим? Всё большее количество людей уходит в онлайн. Всё большее количество людей начинает пользоваться смартфонами и как следствие -- онлайн торговлей. А этим системам чтобы выдерживать всё нарастающие нагрузки хочется сэкономить: арендовывать меньшее количество серверов при всё нарастающих потребностях. И поверьте: эпоха сети Интернет только взяла старт: в прошлое уйдёт население, не принимающее современных технологий, а на смену ему придёт поколение, не знающее другого пути. И даже если серверные системы будущего будут выдерживать нагрузки в 1,000 раз большие.. Конечно же сайты "попроще" могут быть написаны как угодно плохо... Но если ваша цель -- работать в компаниях топового уровня, оптимизацией вы будете заниматься всегда.
[>]: Касательно этого вопроса, конечно же, может существовать множество мнений. Однако, как опыт так и статистика по зарплатам на различных порталах говорит нам о том, что вектор развития индустрии именно такой.
Программисты, на мой взгляд, разделятся если можно так выразиться на классы: это деление уже в некотором смысле началось. Однако сегментация будет более выраженной: на мой взгляд сливки будут снимать люди с хорошим математическим аппаратом. Эти люди будут решать вопросы разработки систем ИИ, нейросетей, потокового шифрования и передачи больших объёмов траффика. Вопросы кратко- и долгосрочного хранения данных, высокоскоростного извлечения данных по нечётким критериям, ассоциативным критериям. Распознания и синтеза образов и речи. Системы слежения за всеми аспектами жизни людей и продажи этой информации через API. Эта работа возможна только со знанием математического аппарата и с глубоким знанием платформы, на которой идёт работа. При этом обилие вывода разработчиков ВУЗами создаст избыточное предложение, излишки которого (желающие остаться в професии, но не имеющие к этому большого таланта) будут заниматься настройкой шаблонов "под магазин". Они будут мастера этого дела: ведь работа эта -- потоковая. И каждый из классов будет, как это принято, иметь зарплатную вилку. Уйти в верхнюю зарплатную вилку помимо всего прочего вам помогут страницы этой книги. Ровно как и создать её этими знаниями.
[>]: Почему так? Недавно я оптимизировал код. Ничего "такого", оптимизация библиотеки SMBLibrary. Если дать на неё нагрузку, она создает траффик в памяти в 10 Гб/сек массивов и мелких объектов. Выделение одного объекта минимальных размеров давало 2 Мб/сек аллокаций. Оптимизировать удалось на 99,9%. Производительность при этом сама собой выросла на 25%. т.е. GC отъедал 25% времени: вдумайтесь. Как итог, она может качать быстрее требуя при этом гораздо меньше ресурсов.
{.big-quote} Рынок высокопроизводительного программного обеспечения создаётся наличием профессионалов, которые своей работой сами создают спрос на себя.
Подсистему управления памятью мы будем изучать, постепенно подбираясь к практике. Согласитесь, знаниям - ноль цена если нет понимания, куда их приложить.
Первым делом мы обоснуем алгоритмистику управления памятью внутри кучи .NET. Т.е. докажем, что она построена правильно. Это будет как часть введения, тренировки ума и программа принятия того, до чего у многих не доходили руки. Далее мы проследуем в описание особенностей устройства и организации работы с памятью. Зачем? Слово "Организация" имеет цену. Выделить память - время. Освободить память - время. На всё нужно время: и прежде всего время нужно нам самим. Жаль, у профилировщиков нет метрики: сколько времени работал Garbage Collector. Я думаю, эта цифра бы заставила многих задуматься. И, нет. Вовсе не о смене языка или платформы. Тут у нас как раз-таки всё просто замечательно. А о том, как можно работать иначе. Чтобы это время стало нашим.
Язык не даёт производительности. Производительность даёт компилятор. Знаете.. Не испротить можно, пожалуй, только язык asm. Потому что это - язык процессора. А вот всё что выше можно написать как аккуранто относясь к деталям, так и в качестве студенческого проекта "чтобы не влепили неуд". Второе, что даёт производительность - наш ум. Если вы влепим в цикл LINQ выражение, создающее, например, по 4 аллокации благодаря использованию замыкания, то нечего удивляться, что на 100,000 итераций цикла создаётся около 4-6 Мб траффика из ниоткуда + 1-2 GC. И если переписать под for(), то картина в корне поменяется и приложение станет чуточку быстрее. Другими словами, профессионал знает инструмент, которым он работает. Проблематику некоторых аспектов языка программирования, платформы, операционной системы и оборудования.
Тут можно сделать вывод, что я - фанат преждевременной оптимизации. Конечно же, нет. Я преверженнец подхода, что часть работы по ускорению приложения разработчик делает просто потому что приобретает опыт написания изначально продуктивного кода: он просто привыкает что-то делать "автоматом". 20% усилий даёт 80% результатов: помните? Другими словами, удерживая в памяти опасность замыканий, опасность любови в LINQ, дублирование строк при их изменении и прочие такие вопросы, вы автоматически пишете код, который работает быстрее, чем тот, который написан без учёта этих опасностей.
Если же ваша программная система начинает упираться в загрузку процессора или в память.. Микросервисы начинают друг другу мешать: тут уже стоит расправить плечи, надевать защитный костюм и погружаться в люк глубинной оптимизации кода.
После тероии мы поговорим про практику. И именно этот раздел будет поделен на две части: преждевременной оптимизации (т.е. то, к чему стоит привыкнуть и что даст 80% успеха) и раздел "когда начинаются проблемы". Там мы поговорим про варианты, когда нам достался никак не оптимизированный код (т.е. нет этих "80%") и когда базовые оптимизации уже сделаны и нам надо сделать "что-то ещё". В разделе практики мы будем учиться писать максимально производительный код. Будем выжимать всё возможное из тех инструментов, которые у нас есть и учиться применять их тогда, когда это делать своевременно.