Станислав Сидристый - Делаем zero-allocation код на примере оптимизации крупной библиотеки

Ближайшая конференция - DotNext 2024, 10 - 11 сентября, Москва + online
Подробности и билеты: jrg.su/x2GKnA
- -
Иногда возникают ситуации, когда код написан хорошо и стабильно. И кода этого очень много: переписывать будет крайне тяжело. Еще в этом коде есть проблема: он выделяет очень много памяти. Память выделяется и освобождается ввиду возросшей нагрузки и как результат - GC молотит на полную катушку.
На примере библиотеки SMBLibrary мы попробуем свести выделения памяти к минимуму, используя ряд выработанных техник, и увидим, насколько тяжелыми могут быть самые простейшие операции.

[@alexanderlogunov5147]

А чё? Так можно было что ли? Я в восторге! Это очень круто!

[@ivan.p]

Спасибо, очень интересно

[@denisstepanenko3037]

Идея пулинга и мемори спанов не нова, но как всегда актуальна

[@alfa9938]

Да в том-то и вопрос, что всё новое - хорошо забытое старое... :) Другое дело, что такой код поддерживать чуть сложнее, чем тот, к которому все привыкли, но профит даёт приличный. А потому почему бы и нет? :)

[@dotnetforever]

Старое или нет, я до сих пор не могу убедить людей это применять. Больше 100ГБ мемори трафика на десктопной апе за 15 минут работы и все вокруг пожимают плечами и спрашивают "А это вообще плохо?". У нас ОЧЕНЬ похожая проблема как Станислав описывает. P.S. Спасибо огромное за книжку! Периодически ссылаюсь на неё.

[@MrMonkAlex]

Кроме пулинга так ничего и не услышал. Часовой доклад, без каких-либо особенностей реализации - скучно.

[@RajaKajiev]

а в чём получился выигрыш относительно LinqFaster ?

[@alfa9938]

Этот вариант вообще не организует трафик по памяти. Все последующие вызовы LINQ используют память предыдущих

[@10199able]

переписываете переписываете переписываете переписываете переписываете переписываете

[@MrAlexanderKot]

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

[@MrCraick0]

бумер изобрел оперативную память Я серьёзно не понимаю зачем? почему это нельзя было написать на си или крестах?

[@superspy2008]

почему вообще нельзя на асме писать сразу код, к чему все эти лишние слои с синтетическим синтаксисом и компиляцией

[@BloobUbloobok]

Уф, звучит как будто вы вкладываете какую то особую коннотацию в слово "бумер" :) Попробую ответить - это ХОЧЕТСЯ написать НЕ на Си или С++, потому что это страдания, это языки особого назначения на которых потом не получится написать ничего иного. C# и .NET лично для меня прекрасны именно потому, что в 80% случаев ты можешь писать работающий и легкочитаемый код, со всем арсеналом управления сложностью домена. Но при необходимости, в тех самых 20% случаев можно превратить ООП код в нечто максимально оптимизированное и работающее максимально быстро. И оно будет на том же языке, разве что с некоторыми изысками.

[@MrCraick0]

@@BloobUbloobok про бумера это отсылка к шутке "бумер изобрёл коммунизм" Вы пишете про плюсы c# в вакууме. Вопрос зачем решать эту задачу посредством шарпа. То что в докладе пытаются использовать есть в том же си из под коробки. Одна из фраз "если не очищать переменную перед тем как вернуть в пулл, получим мусор", вот ловлю я вьтнамские флешбеки) Это интересно выглядит, но все равно это выглядит как велосипед на костыльной тяге.

[@BloobUbloobok]

@@MrCraick0 собственно ответ будет примерно тот же - зато в 80% остальных случаев можно быстро писать на удобном языке C# не задумываясь о таких оптимизациях, не задумываясь об очистке мусора, концентрируясь только на бизнес-логике и решении задачи. А вот уж когда надо сделать максимально быстро, садишься и пишешь специальный точный код, но используя ровно тот же самый понятный язык программирования.

[@leobreydo9318]

@@BloobUbloobok Друг мой, это не с++ плохой или неудобный - это вы его плохо знаете 😕