_В сегодняшнем посте мы предлагаем вам расшифровку доклада Андрея [DreamWalker][1] Акиньшина с [DotNext 2017 Piter][2] о памяти, в котором Андрей разбирает, как работает память с точки зрения производительности приложений. Пост получился огромный, так что запасайтесь кофе и терпением._
Все мы хотим, чтобы программы, которые мы пишем, работали быстрее и кушали мало памяти. Поэтому практически всем программистам приходится заниматься перформансными работами разной степени сложности. И в ходе оптимизации главное — не хвататься за первый попавшийся кусок кода. Лучше найти узкое место программы, в которое упирается производительность. Можно сколько угодно оптимизировать другие места, но, скорее всего, эффект будет не очень заметный.
К сожалению, поиск узких мест — зачастую нетривиальная задача. Но с типом узкого места чаще всего удаётся определиться. Это может быть, например, процессор, доступ к базе данных, к диску или к сети. Один из распространённых кейсов — это доступ к основной памяти. Думаю, просто потому, что с основной памятью мы работаем чаще всего.
С точки зрения перформанса память — штука очень коварная и непонятная. Будем разбираться с тем, как она работает.
![][3]
В этом докладе с [DotNext 2017 Piter][4] мы поговорим о том, что влияет на скорость работы с памятью. Обсудим как низкоуровневые хардварные штуки (CPU cache и его ассоциативность, выравнивание, store forwarding, 4K aliasing, prefetching, cache/page splits, cache bank conflicts и т.п.), так и более .NET-специфичные проблемы (pinned objects, large object heap, особенности работы кучи в полном .NET Framework и Mono).
[Читать дальше →][5]
[1]:
https://habrahabr.ru/users/dreamwalker/
[2]:
https://dotnext-piter.ru/
[3]:
https://habrastorage.org/web/35f/6e3/95b/35f6e395ba044b3c806d7181a109745e.jpeg
[4]:
https://dotnext-piter.ru/
[5]:
https://habrahabr.ru/post/335832/?utm_source=habrahabr&utm_medium=rss&utm_campaign=feed_posts#habracut