Что делает параметр buffered в сети точек Dapper?

но, насколько я могу судить, единственное, что он делает, это приводит результат к списку, прежде чем вернуть его

Вы ничего не упускаете. Это ключевое отличие. За исключением того, что это не приведение как таковое: фактически возвращаемый объект сильно отличается. По сути, есть два способа чтения данных:

• в потоковом API каждый элемент передается отдельно; это очень эффективно использует память, но если вы выполняете много последующей обработки для каждого элемента, это означает, что ваше соединение / команда может быть «активной» в течение длительного времени.
• в буферизованном API все строки считываются прежде чем что-либо будет получено

Если вы читаете очень большой объем данных (от тысяч до миллионов строк), небуферизованный API может быть предпочтительнее. В противном случае используется много памяти, и может возникнуть заметная задержка еще до того, как будет доступна первая строка. Однако в большинстве распространенных сценариев объем считываемых данных находится в разумных пределах, поэтому разумно поместить их в список перед передачей вызывающей стороне. Это означает, что команда /reader и т. д. завершилась до возврата.

В качестве примечания, буферизованный режим также позволяет избежать очень распространенного «уже есть открытое средство чтения в соединении» (или что-то еще в точной формулировке).

Я должен не согласиться с @chris-marisic в этом... Я столкнулся с несколькими исключениями «Недостаточно памяти» именно в этой строке (data.ToList()) при использовании buffered:true. Это был не запрос «миллион строк X базиллион столбцов», а просто обычный SQL-результат из 5-6 тысяч строк с примерно 30 столбцами.

Это действительно зависит от вашей конфигурации. Например. независимо от того, работают ли ваши SQL и IIS на одной физической машине или нет. И сколько памяти установлено на машине IIS, и каковы настройки файла подкачки и т. д. Если веб-сервер имеет 2 ГБ или меньше - рассмотрите возможность установки «буферизованного: ложь» для сверхтяжелых отчетов.

На практике лучше никогда не использовать buffered: false.

Я обнаружил, что, читая даже многие миллионы строк, быстрее и эффективнее использовать буферизованные результаты, чем небуферизованные. Возможно, есть точка пересечения, если в ваших таблицах 500 столбцов, и вы читаете десятки миллионов или сотни миллионов строк.

Если ваши наборы результатов меньше многих миллиардов значений, по какой-либо причине не стоит использовать buffered: false.

Во время фактического анализа я был шокирован тем, что чтение гигабайт данных с Sql Server было быстрее (в 2-6 раз быстрее) и более эффективно использовало память в стандартном буферизованном режиме. Повышение производительности учитывает даже самую маленькую возможную операцию, добавление объекта в разреженный массив по индексу в массив, размер которого не изменяется. При переключении разреженного массива размером в несколько гигабайт с небуферизованного на буферизованное время загрузки увеличилось в 2 раза. Запись в словарь с использованием буферизации привела к 6-кратному увеличению времени загрузки при вставке миллионов записей (словарь использовал int PK таблицы в качестве ключа, чтобы максимально возможно было вычислить хэш-код).

Как и во всем, что касается производительности, вы всегда должны анализировать. Однако я могу сказать вам с очень высокой степенью уверенности: всегда начинайте с буферизованного по умолчанию поведения Dapper.