Re[2]: Управление памятью в .NET для профессионалов
От: Pzz Россия https://github.com/alexpevzner
Дата: 01.02.22 16:24
Оценка: +5 :))) :))
Здравствуйте, СвободуАнжелеДевис, Вы писали:

S>>Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603


САД>нормальных ссылок на нормальные источники на нормальном языке есть?


Ну на украинском-то вряд ли...
Re[2]: Управление памятью в .NET для профессионалов
От: Pzz Россия https://github.com/alexpevzner
Дата: 01.02.22 16:46
Оценка: +5 -2
Здравствуйте, Kolesiki, Вы писали:

K>Практически никогда. Собственно, для того GC-языки и делали, чтобы НАВСЕГДА ЗАБЫТЬ, что такое "память"! И после C# смотреть на потуги rust'оманов — всё равно, что смотреть на забег безногих на Эверест.


Беда в том, что иногда оно о себе напоминает. И вот тут-то и проявляется разница между профессионалом и любителем: профессионал потратит некое конечное время и разберется, в чем проблема. А любитель будет бегать вокруг, кудахтать, хлопать крыльями и твердить "так не бывает! это бага в компиляторе! у меня все правильно! это бага в рантайме!". Ну, потом придет, конечно, профессионал, и починит.
Re[5]: Управление памятью в .NET для профессионалов
От: Михаил Романов Удмуртия https://mihailromanov.wordpress.com/
Дата: 02.02.22 05:44
Оценка: 15 (3)
Здравствуйте, Sinclair, Вы писали:

S>Память начала потихонечку течь.

У нас тогда же была в чем-то схожая проблема с сериализатором XML.

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

Для борьбы с таким поведением MS сделали пул сериализаторов, но он работал только для случая, когда сериализатор создавался/получался по 1 единственному параметру (типу корневого узла).
Пока мы создавали сериализатор таким простым способом — проблем не было.
Но потом нам потребовалось создавать его более сложным способом, передавая массив knownTypes. Этот массив был всегда фиксирован, т.е. параметры создания оставались неизменными от вызова к вызову, но тут уже код сериализатора генерировался заново каждый раз.

К счастью проблему мы отловили еще до релиза — отдел тестирования сделал нагрузочный тест, на котором наш сервис за ночь сожрал всю память. К сожалению, с дампами мы тогда работать не умели (стыдно сказать я и до сих пор не особо умею), поэтому ловили проблему по Performance Counters. Оказалось, что у процесса managed память остаётся примерно на одном уровне, а вот unmanaged прирастает на примерно одно и то же значение.

В целом — банально, конечно, но тем не менее...
Re: Управление памятью в .NET для профессионалов
От: Kolesiki  
Дата: 01.02.22 14:47
Оценка: -2 :)
Здравствуйте, Shmj, Вы писали:

S>Управление памятью в .NET

S>Как часто подобное вам пригождалось на практике?

Практически никогда. Собственно, для того GC-языки и делали, чтобы НАВСЕГДА ЗАБЫТЬ, что такое "память"! И после C# смотреть на потуги rust'оманов — всё равно, что смотреть на забег безногих на Эверест.
Re: Управление памятью в .NET для профессионалов
От: Ночной Смотрящий Россия  
Дата: 01.02.22 19:37
Оценка: +1 -1 :)
Здравствуйте, Shmj, Вы писали:

S>Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?


Если речь о более менее нагруженных серверных решениях — чуть более чем всегда. На десктопе — практически никогда.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Управление памятью в .NET для профессионалов
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.02.22 13:39
Оценка: +3
Здравствуйте, Kolesiki, Вы писали:
K>И каким боком это к программистам?! Нашёл утечку и она не твоя — рапортуй в Рэдмонд, делов-то! Это их проблема — ковыряться на системном уровне, ОБЫЧНОМУ программисту это не нужно.
А ещё можно в канализационную трубу орать.
Я имею опыт взаимодействия с Рэдмондом. В самом лучшем случае решение займёт месяцы. А в приведённом случае — годы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: Управление памятью в .NET для профессионалов
От: hardcase Пират http://nemerle.org
Дата: 02.02.22 13:49
Оценка: 61 (2)
Здравствуйте, vaa, Вы писали:

vaa>Простите, что вмешиваюсь. А можете привести пример кода?


Код не покажу, но истории разные: повисшие подписки на событиях (любое приложение), нетривиальные алгоритмы потребляющие память (анализаторы исходного кода), как-то даже была утечка тасок

Лечилось всегда вдумчивым изучением дампов.

З.Ы. Однажды была история с утечкой нативных хэндлов из-за ошибки в реалзиации IDisposable в каком-то из старых дотнетов.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Отредактировано 02.02.2022 13:53 hardcase . Предыдущая версия .
Re[4]: Управление памятью в .NET для профессионалов
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.02.22 04:24
Оценка: 11 (2)
Здравствуйте, vaa, Вы писали:
vaa>Простите, что вмешиваюсь. А можете привести пример кода?
Во времена второго дотнета при создании регекспа с опцией compiled порождался код, который не выгружался из домена никогда. Заодно этот код держал ссылку на исходную строку.

У нас был код, который создавал регексп на одном из путей исполнения. Регексп потом применялся ко многим объектам (не помню деталей — мы, наверное, искали фрагмент в наборе файлов), поэтому для ускорения мы включили ему compiled.
Память начала потихонечку течь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Управление памятью в .NET для профессионалов
От: Sharov Россия  
Дата: 01.02.22 14:33
Оценка: 1 (1) +1
Здравствуйте, Shmj, Вы писали:

S>Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?


У него можно курс купить, правда дико дорогой -- https://dotnetmemoryexpert.com/
Плюс он сделал очень крутые постеры -- http://tooslowexception.com/wp-content/uploads/2019/08/gcposter05.png
http://tooslowexception.com/wp-content/uploads/2019/08/gcposter06.png

Я бы взял курс -- у него их много, но уж больно дорого. За бандл(.net performance, mem. managment, async) я бы может
и дал такие деньги, а за один курс -- жаба душит.

Да, еще тест есть -- https://quiz.dotnetmemoryexpert.com/
Кодом людям нужно помогать!
Re[5]: Управление памятью в .NET для профессионалов
От: Doom100500 Израиль  
Дата: 02.02.22 07:41
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vaa, Вы писали:

vaa>>Простите, что вмешиваюсь. А можете привести пример кода?
S>Во времена второго дотнета при создании регекспа с опцией compiled порождался код, который не выгружался из домена никогда. Заодно этот код держал ссылку на исходную строку.

S>У нас был код, который создавал регексп на одном из путей исполнения. Регексп потом применялся ко многим объектам (не помню деталей — мы, наверное, искали фрагмент в наборе файлов), поэтому для ускорения мы включили ему compiled.

S>Память начала потихонечку течь.

Простите, конечно, и меня, но разве это ли не баг в компиляторе/рантаиме и так не бывает? И как профессионал решил эту проблему (с оставлением опции compiled для ускорения)?
Спасибо за внимание
Re[5]: Управление памятью в .NET для профессионалов
От: Kolesiki  
Дата: 03.02.22 13:30
Оценка: :))
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vaa, Вы писали:

vaa>>Простите, что вмешиваюсь. А можете привести пример кода?
S>Во времена второго дотнета....
S>Память начала потихонечку течь.

И каким боком это к программистам?! Нашёл утечку и она не твоя — рапортуй в Рэдмонд, делов-то! Это их проблема — ковыряться на системном уровне, ОБЫЧНОМУ программисту это не нужно.
Re[2]: Управление памятью в .NET для профессионалов
От: romangr Россия  
Дата: 01.02.22 13:14
Оценка: 1 (1)
Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>нормальных ссылок на нормальные источники на нормальном языке есть?


https://link.springer.com/book/10.1007/978-1-4842-4027-4
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[6]: Управление памятью в .NET для профессионалов
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.02.22 11:55
Оценка: 1 (1)
Здравствуйте, Doom100500, Вы писали:
D>Простите, конечно, и меня, но разве это ли не баг в компиляторе/рантаиме и так не бывает?
Можно сказать, что баг; можно — что особенность.
D>И как профессионал решил эту проблему (с оставлением опции compiled для ускорения)?
Сохранили наш регексп в static-поле, получив 1 экземпляр на всё время жизни приложения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Управление памятью в .NET для профессионалов
От: Shmj Ниоткуда  
Дата: 01.02.22 12:49
Оценка: +1
Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603

По глубине погружения похожа на Рихтера. Язык весьма доступен, но инфа не сжатая.

Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?
Re: Управление памятью в .NET для профессионалов
От: СвободуАнжелеДевис СССР  
Дата: 01.02.22 13:02
Оценка: :)
S>Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603

нормальных ссылок на нормальные источники на нормальном языке есть?
Нет времени на раскачку!
Re: Управление памятью в .NET для профессионалов
От: Степанов Андрей  
Дата: 01.02.22 16:01
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603


S>По глубине погружения похожа на Рихтера. Язык весьма доступен, но инфа не сжатая.


S>Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?


За мои примерно 15 лет опыта разработки на .NET пару раз была утечка памяти, которая заставила реально напрячься. Из них один раз пришлось снимать дамп памяти и искать по нему объекты в куче. Почитать интересно, но только если есть свободное время.
Re[3]: Управление памятью в .NET для профессионалов
От: Kolesiki  
Дата: 03.02.22 13:28
Оценка: -1
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Kolesiki, Вы писали:


K>>Практически никогда. Собственно, для того GC-языки и делали, чтобы НАВСЕГДА ЗАБЫТЬ, что такое "память"! И после C# смотреть на потуги rust'оманов — всё равно, что смотреть на забег безногих на Эверест.


Pzz>Беда в том, что иногда оно о себе напоминает


Иногда — т.е. далеко не у всех и не всегда. Мне повезло — практически никогда не сталкивался с тем, чтобы лезть куда-то под капот — приложения работали прекрасно на стандартных API.


Pzz>И вот тут-то и проявляется разница между профессионалом и любителем...


А! Так ты просто повыпежониваться вылез! Я-то думал! Так сразу и напиши: "Я, Пзз, профи, а Колёсики — нет!" и не тратил бы моё время своими глупыми приседаниями вокруг своей профессиональной личности!

Pzz>: профессионал потратит некое конечное время и разберется, в чем проблема


С чем именно разберётся?? Ты сам себе придумал проблему и сам её уже решил? Причём такую проблему, что никто кроме Pzz её не решит?! Клоун Фантазёр форумный!
Re[7]: Управление памятью в .NET для профессионалов
От: Pavel Dvorkin Россия  
Дата: 03.02.22 13:33
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>Сохранили наш регексп в static-поле, получив 1 экземпляр на всё время жизни приложения.


Хороший пример, кстати, демонстрирующий разную психологию отношения к памяти.

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

А вот программист, пришедший из C++/Pascal в управляемый язык, скорее всего сразу подумал бы, что одной переменной хватит. static или иначе — это детали, а вот на каждый new нужен delete, и с какой это стати я буду каждый раз в этом "цикле" new-delete делать, если можно вынести и поставить до "цикла" ?
With best regards
Pavel Dvorkin
Re[9]: Управление памятью в .NET для профессионалов
От: Doom100500 Израиль  
Дата: 03.02.22 13:52
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Примерная логика — вот такая:

S>
S>public IEnumerable<FileRef> GetIncompleteFiles()
S>{
S>   var r = new Regex("\\/\\/ TODO:.*$", RegexOptions.Compiled);

S>   foreach(var f in this.Project.GetAllFileRefs())
S>      if (r.Match(f.GetContents())
S>         yield return f;
S>}
S>

S>Вполне себе невинный код. И в С++ такое запросто — у меня обычная auto-переменная, никаких тебе delete, разрушится по выходу из скоупа.

Эээ... Но ведь компилирование регекспа — это не самая лёгкая задача. Я интуитивно такие вещи в инициализацию куда-то вынишу.
Спасибо за внимание
Re[10]: Управление памятью в .NET для профессионалов
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.02.22 14:33
Оценка: +1
Здравствуйте, Doom100500, Вы писали:
D>Эээ... Но ведь компилирование регекспа — это не самая лёгкая задача. Я интуитивно такие вещи в инициализацию куда-то вынишу.
Там на фоне стоимости обработки данных — несущественные семечки. Код бенчмаркали — он сильно ускорился после включения compiled. Создавать ещё один gc root — ну, такое себе решение.
Его надо принимать осознанно
Ну, и, конечно, на тот момент у нас опыта с дотнетом было недостаточно, чтобы такие вещи применять "интуитивно".
Кстати, примерно во времена третьего шарпа и дотнета 4.0 эта проблема была полностью устранена, в связи с реализацией DynamicMethod.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: Управление памятью в .NET для профессионалов
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.02.22 14:45
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А тут да, действительно автоматическая переменная. Вот только в C++ не было бы никакого new, и создавалась бы она на стеке, а там уничтожение автоматическое и гарантировано в известный момент, об этом и впрямь можно не очень думать. А если бы я хотел new, то пришлось бы в С++ либо Regex*, либо Regex& и delete. Далее см. мое предыдущее сообщение.
Павел, тут мышление С++ программистов никак не помогло бы и не помешало. Ну был бы у вас там new и delete — и дальше что?
Можно подумать, в вашем коде не бывает new и delete для локальных переменных.
Проблема-то — не в этом. Проблема — в том, что "вызов delete" на такой переменной освобождал не всю память.

На С++ запросто можно сделать такие же грабли — допустим, опция compiled будет динамически порождать исполняемый код, а вот освобождать она его почему-то не будет. VirtualAlloc будет делаться, а вот VirtualFree — нет.
Например, просто разработчик про это забыл. Не добавил этот VirtualFree в деструктор.
Или неправильно сделал подсчёт ссылок на исполняемый код при копировании regex.
Или вообще решил, что делать на каждый Regex отдельный VirtualAlloc — это оверкилл, и лучше сделать общую арену для динамического кода, которая будет освобождаться каким-то другим способом, не в момент вызова деструктора экземпляра regex.

В итоге — результат один: прикладной разработчик, не обладая глубокими знаниями о потрошках этого Regex, может получить точно такую же утечку. И точно так же он может её не заметить, если программа работает не 24*7.

То, как это было сделано в старом дотнете — не ошибка разработчика RegEx, а ограничение платформы.

Обсуждаемый вопрос — это что с этим делать. Вот у нас тут по соседству есть фанат точки зрения "не мои проблемы" — ну, течёт приложение и течёт. "Наверное, баг платформы".
Нам вот было интересно разобраться. Разбираться настолько глубоко, как в приведённых в топике книгах и картинках, не потребовалось, но понять, что вообще происходит — пришлось.
Ну, а после этого уже было очевидно, что можно сделать для решения проблемы.
А могло так оказаться, что реально найден баг в платформе. Тогда разборки дали бы возможность построить минимально воспроизводящий пример и отправить в Редмонд.
И так понятно, что никто в Редмонде не стал бы гонять наше приложение 72 часа под нагрузкой, чтобы найти причины утечки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Управление памятью в .NET для профессионалов
От: romangr Россия  
Дата: 01.02.22 13:13
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603


S>По глубине погружения похожа на Рихтера. Язык весьма доступен, но инфа не сжатая.


S>Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?


Покупал в конце 2018 года в Apress, там были скидки и вышло очень недорого.
Если интересно узнать во всех подробностях, как в .net устроен GC и вообще управление памятью — книга очень даже хороша.
У Кокосы и на Youtube есть лекции по этой теме.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re: Управление памятью в .NET для профессионалов
От: Sharowarsheg  
Дата: 01.02.22 16:30
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603


Конкретно это — нет, но что-то похожее читал.

S>Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?


Если много данных обрабатывать, то приходится думать, а то медленно получается.
Re[3]: Управление памятью в .NET для профессионалов
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 02.02.22 01:28
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Беда в том, что иногда оно о себе напоминает. И вот тут-то и проявляется разница между профессионалом и любителем: профессионал потратит некое конечное время и разберется, в чем проблема. А любитель будет бегать вокруг, кудахтать, хлопать крыльями и твердить "так не бывает! это бага в компиляторе! у меня все правильно! это бага в рантайме!". Ну, потом придет, конечно, профессионал, и починит.


Простите, что вмешиваюсь. А можете привести пример кода?
Re: Управление памятью в .NET для профессионалов
От: Vladek Россия Github
Дата: 02.02.22 13:58
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603


S>По глубине погружения похожа на Рихтера. Язык весьма доступен, но инфа не сжатая.


S>Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?


Книга есть. Пишу разные парсеры (html, xpath, jpath, csv, дроби, деньги, и прочий текст), где приходится следить за созданием объектов много работать со строками — глава 14 пригождалась.
http://files.rsdn.org/43395/hr-kyle-theisen-04.png
Re[8]: Управление памятью в .NET для профессионалов
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.02.22 13:44
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот программист, пришедший из C++/Pascal в управляемый язык, скорее всего сразу подумал бы, что одной переменной хватит. static или иначе — это детали, а вот на каждый new нужен delete, и с какой это стати я буду каждый раз в этом "цикле" new-delete делать, если можно вынести и поставить до "цикла" ?
Оно и так стояло до "цикла".
Примерная логика — вот такая:
public IEnumerable<FileRef> GetIncompleteFiles()
{
   var r = new Regex("\\/\\/ TODO:.*$", RegexOptions.Compiled);

   foreach(var f in this.Project.GetAllFileRefs())
      if (r.Match(f.GetContents())
         yield return f;
}

Вполне себе невинный код. И в С++ такое запросто — у меня обычная auto-переменная, никаких тебе delete, разрушится по выходу из скоупа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[9]: Управление памятью в .NET для профессионалов
От: Pavel Dvorkin Россия  
Дата: 03.02.22 13:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Оно и так стояло до "цикла".

S>public IEnumerable<FileRef> GetIncompleteFiles()

Я имел в виду до "цикла" по GetIncompleteFiles.

А тут да, действительно автоматическая переменная. Вот только в C++ не было бы никакого new, и создавалась бы она на стеке, а там уничтожение автоматическое и гарантировано в известный момент, об этом и впрямь можно не очень думать. А если бы я хотел new, то пришлось бы в С++ либо Regex*, либо Regex& и delete. Далее см. мое предыдущее сообщение.
With best regards
Pavel Dvorkin
Re[11]: Управление памятью в .NET для профессионалов
От: Pavel Dvorkin Россия  
Дата: 03.02.22 15:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Павел, тут мышление С++ программистов никак не помогло бы и не помешало. Ну был бы у вас там new и delete — и дальше что?


Я же написал — дальше вопрос, нужно ли это в "цикле". Потому что психологически программист на C++ не склонен к лишним new, поскольку помнит про delete. Вот и все.

S>Можно подумать, в вашем коде не бывает new и delete для локальных переменных.


Бывает, но если иначе нельзя.

S>Проблема-то — не в этом. Проблема — в том, что "вызов delete" на такой переменной освобождал не всю память.


S>На С++ запросто можно сделать такие же грабли — допустим, опция compiled будет динамически порождать исполняемый код, а вот освобождать она его почему-то не будет. VirtualAlloc будет делаться, а вот VirtualFree — нет.

S>Например, просто разработчик про это забыл. Не добавил этот VirtualFree в деструктор.

Ну это то же самое. new-delete в другой упаковке. Если она на С++ пишет и грамотный специалист — должен об этом сразу думать.


S>В итоге — результат один: прикладной разработчик, не обладая глубокими знаниями о потрошках этого Regex, может получить точно такую же утечку. И точно так же он может её не заметить, если программа работает не 24*7.


Не обязан программист на С++ знать устройство всех классов STL или boost, а равно и других. Хватит, если в Regex нет ошибок и он правильно выделяет и освобождает память.
With best regards
Pavel Dvorkin
Re[11]: Управление памятью в .NET для профессионалов
От: Doom100500 Израиль  
Дата: 03.02.22 15:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну, и, конечно, на тот момент у нас опыта с дотнетом было недостаточно, чтобы такие вещи применять "интуитивно".


Да я это, скорее, с точки зрения C++ писал как раз.
Но дело не этом. Я сам склонен разбираться до конца и найти проблему прежде всего у себя и не верить в баги комилятора и библиотек до последнего (но, в последнее время это мнение становится всё менее устойчивым ).
И книжку бы почитал, но в электронном виде. В форме 30-60 минут в день.

Edit:
Книга, кстати, интересная. Там не только про дотнет...
Спасибо за внимание
Отредактировано 03.02.2022 17:27 Doom100500 . Предыдущая версия .
Re[2]: Управление памятью в .NET для профессионалов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.02.22 22:53
Оценка:
Здравствуйте, romangr, Вы писали:

R>У Кокосы и на Youtube есть лекции по этой теме.


Что за кокос?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Управление памятью в .NET для профессионалов
От: Shmj Ниоткуда  
Дата: 09.02.22 17:56
Оценка:
Здравствуйте, VladD2, Вы писали:

R>>У Кокосы и на Youtube есть лекции по этой теме.

VD>Что за кокос?

Автор: Кокоса Конрад

Фамилиё такое.
Re: Управление памятью в .NET для профессионалов
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 10.02.22 02:51
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Читали ли вы это: https://www.ozon.ru/product/upravlenie-pamyatyu-v-net-dlya-professionalov-kokosa-konrad-363285603


S>По глубине погружения похожа на Рихтера. Язык весьма доступен, но инфа не сжатая.


S>Вопрос вот в чем. Как часто подобное вам пригождалось на практике? Или даже не думаете о этом?


В книге представлены:
— теоретические основы автоматического управления памятью;
— глубокое погружение во все аспекты управления памятью в .NET, в т. ч. подробное описание реализации сборщика мусора (GC);
— практические советы по разработке реальных программ;
— правила использования инструментов, относящихся к управлению памятью в .NET;
эффективные методы работы с памятью, включая типы Span и Memory.


Кроме последнего пункта всё остальное для того и сделано, чтобы .Net-разработчику не думать о таких деталях.
Позволю процитировать себе Александреску в отношении rust(как самого замороченного на управлении памятью):
"этот парень пропускал дни кача ног(мем)".
Re[2]: Управление памятью в .NET для профессионалов
От: Shmj Ниоткуда  
Дата: 10.02.22 06:57
Оценка:
Здравствуйте, vaa, Вы писали:

vaa>Кроме последнего пункта всё остальное для того и сделано, чтобы .Net-разработчику не думать о таких деталях.

vaa>Позволю процитировать себе Александреску в отношении rust(как самого замороченного на управлении памятью):
vaa>"этот парень пропускал дни кача ног(мем)".

Там приведен пример, когда при переборе элементов 2-мерного массива видна практическая разница в скорости доступа — это протягивается с уровня процессора и никаким образом не может быть изменено даже на таком высоком уровне как .Net программа.
Re[2]: Управление памятью в .NET для профессионалов
От: IQuerist Мухосранск  
Дата: 02.03.22 09:57
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Практически никогда.


При этом, память и GC это первая тема на собесах. Люди не представляют как их кривые мапинги из ORM через dynamic прямо в ад н...й в json без знания литаний о поколениях GC можно поддерживать.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.