C# Heppard

ObjectPool #память #решение

Есть такая работа - ObjectPool. Это когда мы не позволяем GC уничтожать объекты, которые живут очень короткое время, а используем их снова и снова. Это очень помогает в экономии памяти.

Если кто не знал, то new - дорогая операция (хотя есть мнение, что нет), которая требует выделить памяти в heap (для классов, конечно же). Ну в куче, которую контролирует GC. Чтобы не заставлять GC работать (а его работа это дорогой обход дерева), мы можем помещать объекты, которые живут не долго, в специальное место - пул. Извлекая их оттуда, мы их переиспользуем, то есть не заставляем их снова и снова появляться в куче.

Существует хорошая библиотека, которая позволяет это делать. Причём не от кого-нибудь, а от вендора. Это быстрая и хорошо написанное решение.

Но что делать, если нам нужно быстрее?

Ответ, как всегда, есть.

1. Велосипед. Это Manual в бенчмарке. В принципе, там нет ничего особенного - я списал какие-то, с моей точки зрения, важные вещи с реализации Microsoft и из другой билиблиотеки. Это решение лаконично и понятно.
2. Можно воспользоваться той самой "другой" библиотекой. Скорость выше не на порядки, но, тем не менее, выше. А хорошее и подробное описание кода может погрузить нас в прекрасный мир высокой производительности.

В результате, мы получим либо аналогичную производительность (но без зависимостей), либо производительность чуть-чуть выше, чем у того, что предлагает нам вендор.

При этом, внимательный читатель наверняка заметил, что самым эффективным пулом для маленьких объектов является некий ConcurrentToolkitLite. Это внутренний класс библиотеки ConcurrentToolkit. Его реализация проста, и основана на том, что существует всего один ThreadStatic объект, который и содержит данные пула. Вот так просто и элегантно.

Если кому-то мало комментариев Евгения и хочется большего, то могу сообщить дополнительно, что имплементация ConcurrentQueue в .NET выросла вот отсюда. Она же, чаще всего, лежит в основах примеров в интернете.

Кода много, поэтому он тут.

👍12🔥5❤4

www.tgoop.com/csharp_gepard/115

2.86K viewsedited  Jun 7, 2024 at 15:11

ObjectPool #память #решение

Есть такая работа - ObjectPool. Это когда мы не позволяем GC уничтожать объекты, которые живут очень короткое время, а используем их снова и снова. Это очень помогает в экономии памяти.

Если кто не знал, то new - дорогая операция (хотя есть мнение, что нет), которая требует выделить памяти в heap (для классов, конечно же). Ну в куче, которую контролирует GC. Чтобы не заставлять GC работать (а его работа это дорогой обход дерева), мы можем помещать объекты, которые живут не долго, в специальное место - пул. Извлекая их оттуда, мы их переиспользуем, то есть не заставляем их снова и снова появляться в куче.

Существует хорошая библиотека, которая позволяет это делать. Причём не от кого-нибудь, а от вендора. Это быстрая и хорошо написанное решение.

Но что делать, если нам нужно быстрее?

Ответ, как всегда, есть.

1. Велосипед. Это Manual в бенчмарке. В принципе, там нет ничего особенного - я списал какие-то, с моей точки зрения, важные вещи с реализации Microsoft и из другой билиблиотеки. Это решение лаконично и понятно.
2. Можно воспользоваться той самой "другой" библиотекой. Скорость выше не на порядки, но, тем не менее, выше. А хорошее и подробное описание кода может погрузить нас в прекрасный мир высокой производительности.

В результате, мы получим либо аналогичную производительность (но без зависимостей), либо производительность чуть-чуть выше, чем у того, что предлагает нам вендор.

При этом, внимательный читатель наверняка заметил, что самым эффективным пулом для маленьких объектов является некий ConcurrentToolkitLite. Это внутренний класс библиотеки ConcurrentToolkit. Его реализация проста, и основана на том, что существует всего один ThreadStatic объект, который и содержит данные пула. Вот так просто и элегантно.

Если кому-то мало комментариев Евгения и хочется большего, то могу сообщить дополнительно, что имплементация ConcurrentQueue в .NET выросла вот отсюда. Она же, чаще всего, лежит в основах примеров в интернете.

Кода много, поэтому он тут.

BY C# Heppard