.NET DB Query Without Allocations?

Question

Мне была поручена перезапись некоторых библиотек, написанных на C#, так что после завершения запуска никаких распределений не будет.

Я только что получил один проект, который выполняет некоторые запросы БД по OdbcConnection каждые 30 секунд. Я всегда использовал .ExecuteReader(), который создает OdbcDataReader. Есть ли какой-либо шаблон (например, шаблон сокета SocketAsyncEventArgs), который позволяет повторно использовать собственный OdbcDataReader? Или какой-нибудь другой умный способ избежать распределения?

Я не удосужился узнать LINQ, так как все dbs на работе основаны на Oracle и последнее, что я проверил, не было официального поставщика Linq To Oracle. Но если в Linq есть способ сделать это, я могу использовать один из сторонних.

Update:

Я не думаю, что четко определены причины требования не-Alloc. У нас есть один критический поток, и очень важно, чтобы он не зависал. Это для торгового приложения в режиме реального времени, и мы наблюдаем до 100 мс замораживания для некоторых коллекций Gen 2. (Я также слышал, что игры пишутся одинаково на C#). Существует один фоновый поток, который выполняет некоторую проверку соответствия и запускается каждые 30 секунд. Он делает запрос db прямо сейчас. Запрос довольно медленный (около 500 мс для возврата со всеми данными), но это нормально, потому что оно не мешает критическому потоку. За исключением случаев, когда рабочий поток выделяет память, это заставит GCs заморозить все потоки.

Мне сказали, что все библиотеки (включая этот) не могут выделить память после запуска. Согласен ли я с этим или нет, это требование от людей, которые подписывают чеки :).

Теперь ясно, что я могу получить данные в этом процессе без выделения. Я мог бы настроить другой процесс и подключить его к этому, используя сокет. Новые сокеты .NET 3.5 были специально оптимизированы, чтобы не выделять их вообще, используя новый шаблон SocketAsyncEventArgs. (На самом деле, мы используем их для подключения к нескольким системам и никогда не видим никаких GC из них.) Затем у вас есть предварительно выделенный массив байтов, который читает из сокета и проходит через данные, не выделяя никаких строк на этом пути. (Я не знаком с другими формами IPC в .NET, поэтому я не уверен, что распределены файлы с памятью и именованные каналы или нет).

Но если есть более быстрый способ получить этот запрос без выделения, не пройдя все эти трудности, я бы предпочел его.

Answer 1

Нельзя использовать повторно IDataReader (или OdbcDataReader или SqlDataReader или любой эквивалентный класс). Они предназначены для использования только с одним запросом. Эти объекты инкапсулируют один набор записей, поэтому, как только вы его получили и повторили, он больше не имеет смысла.

Создание считывателя данных - это невероятно дешевая операция в любом случае, исчезающе малая, в отличие от стоимости фактического выполнения запроса. Я не вижу логической причины для этого требования «без распределения».

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

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

Answer 2

Для такого требования вы уверены, что язык высокого уровня, такой как C#, является вашим выбором?
Вы не можете сказать, являются ли используемые вами функции библиотеки .NET внутренним распределением памяти или нет. Стандарт не гарантирует этого, поэтому, если они не используют распределения в текущей версии .NET framework, они могут начать делать это позже.

Answer 3

Я предлагаю вам профилировать приложение, чтобы определить, где тратится время и/или память. Не догадывайтесь - вы ошибаетесь только.