Да в том-то и вопрос, что всё новое - хорошо забытое старое... :) Другое дело, что такой код поддерживать чуть сложнее, чем тот, к которому все привыкли, но профит даёт приличный. А потому почему бы и нет? :)
Старое или нет, я до сих пор не могу убедить людей это применять. Больше 100ГБ мемори трафика на десктопной апе за 15 минут работы и все вокруг пожимают плечами и спрашивают "А это вообще плохо?". У нас ОЧЕНЬ похожая проблема как Станислав описывает. P.S. Спасибо огромное за книжку! Периодически ссылаюсь на неё.
Вот вот да вот вот... В принципе интересно, но слушать кошмар. К алокейшен- фри алгоритмам ещё бы и вот-фри изложение. Как можно делать столько докладов на конференциях и не научиться избегать слов паразитов, вот?
Уф, звучит как будто вы вкладываете какую то особую коннотацию в слово "бумер" :) Попробую ответить - это ХОЧЕТСЯ написать НЕ на Си или С++, потому что это страдания, это языки особого назначения на которых потом не получится написать ничего иного. C# и .NET лично для меня прекрасны именно потому, что в 80% случаев ты можешь писать работающий и легкочитаемый код, со всем арсеналом управления сложностью домена. Но при необходимости, в тех самых 20% случаев можно превратить ООП код в нечто максимально оптимизированное и работающее максимально быстро. И оно будет на том же языке, разве что с некоторыми изысками.
@@BloobUbloobok про бумера это отсылка к шутке "бумер изобрёл коммунизм" Вы пишете про плюсы c# в вакууме. Вопрос зачем решать эту задачу посредством шарпа. То что в докладе пытаются использовать есть в том же си из под коробки. Одна из фраз "если не очищать переменную перед тем как вернуть в пулл, получим мусор", вот ловлю я вьтнамские флешбеки) Это интересно выглядит, но все равно это выглядит как велосипед на костыльной тяге.
@@MrCraick0 собственно ответ будет примерно тот же - зато в 80% остальных случаев можно быстро писать на удобном языке C# не задумываясь о таких оптимизациях, не задумываясь об очистке мусора, концентрируясь только на бизнес-логике и решении задачи. А вот уж когда надо сделать максимально быстро, садишься и пишешь специальный точный код, но используя ровно тот же самый понятный язык программирования.
А чё? Так можно было что ли?
Я в восторге! Это очень круто!
Спасибо, очень интересно
Идея пулинга и мемори спанов не нова, но как всегда актуальна
Да в том-то и вопрос, что всё новое - хорошо забытое старое... :) Другое дело, что такой код поддерживать чуть сложнее, чем тот, к которому все привыкли, но профит даёт приличный. А потому почему бы и нет? :)
Старое или нет, я до сих пор не могу убедить людей это применять. Больше 100ГБ мемори трафика на десктопной апе за 15 минут работы и все вокруг пожимают плечами и спрашивают "А это вообще плохо?".
У нас ОЧЕНЬ похожая проблема как Станислав описывает.
P.S. Спасибо огромное за книжку! Периодически ссылаюсь на неё.
а в чём получился выигрыш относительно LinqFaster ?
Этот вариант вообще не организует трафик по памяти. Все последующие вызовы LINQ используют память предыдущих
переписываете переписываете переписываете переписываете переписываете переписываете
Кроме пулинга так ничего и не услышал. Часовой доклад, без каких-либо особенностей реализации - скучно.
Вот вот да вот вот...
В принципе интересно, но слушать кошмар. К алокейшен- фри алгоритмам ещё бы и вот-фри изложение.
Как можно делать столько докладов на конференциях и не научиться избегать слов паразитов, вот?
бумер изобрел оперативную память
Я серьёзно не понимаю зачем? почему это нельзя было написать на си или крестах?
почему вообще нельзя на асме писать сразу код, к чему все эти лишние слои с синтетическим синтаксисом и компиляцией
Уф, звучит как будто вы вкладываете какую то особую коннотацию в слово "бумер" :)
Попробую ответить - это ХОЧЕТСЯ написать НЕ на Си или С++, потому что это страдания, это языки особого назначения на которых потом не получится написать ничего иного.
C# и .NET лично для меня прекрасны именно потому, что в 80% случаев ты можешь писать работающий и легкочитаемый код, со всем арсеналом управления сложностью домена. Но при необходимости, в тех самых 20% случаев можно превратить ООП код в нечто максимально оптимизированное и работающее максимально быстро. И оно будет на том же языке, разве что с некоторыми изысками.
@@BloobUbloobok про бумера это отсылка к шутке "бумер изобрёл коммунизм"
Вы пишете про плюсы c# в вакууме. Вопрос зачем решать эту задачу посредством шарпа. То что в докладе пытаются использовать есть в том же си из под коробки. Одна из фраз "если не очищать переменную перед тем как вернуть в пулл, получим мусор", вот ловлю я вьтнамские флешбеки) Это интересно выглядит, но все равно это выглядит как велосипед на костыльной тяге.
@@MrCraick0 собственно ответ будет примерно тот же - зато в 80% остальных случаев можно быстро писать на удобном языке C# не задумываясь о таких оптимизациях, не задумываясь об очистке мусора, концентрируясь только на бизнес-логике и решении задачи. А вот уж когда надо сделать максимально быстро, садишься и пишешь специальный точный код, но используя ровно тот же самый понятный язык программирования.
@@BloobUbloobok Друг мой, это не с++ плохой или неудобный - это вы его плохо знаете 😕