.NET пулы объектов IAsyncResult

Question

Прочитав SendAsync, BeginAsync иллюстрации метода Socket s, я понял, что было предложено объединить SocketAsyncEventArgs экземпляров, говоря, что это лучше, чем BeginXX, EndXX асинхронный подход, так как каждый вызов создает IAsyncResult экземпляр.

Я подумал, что не очень хорошая практика объединять объекты, которые могут быть легко созданы (например, SocketAsyncEventArgs). Распределение объектов довольно быстрое, и GC оптимизирован для эффективной обработки недолговечных объектов. Я попробовал это реализовать механизм пула, чтобы увидеть, как он работает, на самом деле распределение происходит быстрее на простых объектах, которые ничего не делают, но инкапсулируют некоторые данные в ctor. (Ну, это было похоже на профилирование СУБД путем отправки миллиардов SELECT 1 операторов, поэтому я здесь.)

Я не спрашиваю, что лучше, я считаю, что профилирование реального приложения даст ответ, но мне просто интересно узнать о преимуществах объединения простых недолговечных объектов. Лучшая производительность GC? Низкая фрагментация памяти? Стоит ли это учитывать при проектировании?

С MSDN

Основная особенность этих улучшений это избегание повторного распределение и синхронизация объекты во время большого объема асинхронный сокет ввода / вывода. Начало / Конец шаблон проектирования в настоящее время реализован классом System.Net.Sockets.Socket требует объект System.IAsyncResult выделяться для каждого асинхронного работа с сокетом.

В новой версии System.Net.Sockets.Socket улучшения класса, асинхронный операции с сокетом описываются повторно используемые объекты SocketAsyncEventArgs выделены и поддерживаются приложение. Высокопроизводительная розетка приложения знают лучше всего количество перекрывающиеся операции с сокетами, которые должны быть устойчивым. Приложение может создать как можно больше SocketAsyncEventArgs объекты, которые он необходимо. Например, если сервер приложение должно иметь 15 сокетов принимать операции, не выполненные вообще раз для поддержки входящего клиента Скорость соединения, он может выделить 15 повторно используемые объекты SocketAsyncEventArgs для этой цели.

Спасибо.

Answer 1

Интерфейс IAsyncResult включает свойство AsyncWaitHandle типа WaitHandle. A WaitHandle потребляет ресурсы операционной системы.

Фактически, WaitHandle реализует интерфейс IDisposable, поэтому класс, реализующий IAsyncResult, должен сам реализовать IDisposable.

Это все, что говорит о том, что сотни экземпляров IAsyncResult не являются проблемой памяти - это проблема ресурсов Новые вызовы сокетов избавляют от необходимости сотен IDisposable объектов, лежащих вокруг.

Answer 2

Кэш без политики истечения срока действия - это утечка памяти. В твоем вопросе нет ничего, что говорило бы о том, что ты считал хорошую политику. Если у вас его нет, не используйте кеш. Если вы это сделаете, то протестируйте его, чтобы увидеть, можете ли вы измерить реальные улучшения.