Можно ли использовать собственный распределитель памяти для LINQ?

Question

Есть ли способ использовать пользовательский распределитель памяти для LINQ?

Например, когда я звоню:

someCollection.Where(x).SelectMany(y).ToList();

Такие методы, как ToList() или OrderBy() всегда будут создаватьновый массив, поэтому будет много GC.С помощью специального распределителя я всегда мог использовать один и тот же список, который будет очищаться и пополняться каждый раз.Я знаю, что повторное использование буферов может привести к проблемам с повторным входом.

Справочная информация, мое приложение - игра, а GC означает заикание.Пожалуйста, не говорите мне «используйте C ++ вместо» или «не используйте LINQ», я знаю, что:)

Answer 1

(Хотя вы просили не предлагать против него, я думаю, этот ответ мог бы помочь сообществу)

LINQ - это средство, построенное поверх CLR, поэтому оно использует распределитель CLR и не может бытьизменилось.Вы можете немного его настроить, например, настроить, следует ли выгружать цикл GC в фоновый поток, но дальше идти нельзя.

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

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

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

Причина отказа отLINQ заключается в том, что это не тот инструмент, который поможет вам решить проблему с необходимыми ограничениями производительности.Кроме того, как указано в комментариях, использование (ab) лямбда-выражений значительно увеличивает нагрузку на память, так как для реализации замыканий создаются вспомогательные объекты.

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