Здравствуйте, Ночной Смотрящий, Вы писали:

НС> но ты берешься выдавать экспертные оценки по количеству запросов, а это на фоне полного незнания тобой предмета полнейший .
EP>Давай пруф-линк. Я вообще-то как раз спрашивал мнение о количестве запросов.

Короче, ты уже скатился до откровенного вранья

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Здесь не имеет значения, я вообще не утверждал что это супер практично. Это пример в контексте утверждения о невозможности, впрочем твоё передёргивание вполне ожидаемо
I>>
I>>Правильно понимаю, твой восторг был вызван не практической ценностью решения, а всего лишь победой над очередной языковой фичей ?

...

EP>Никаких побед над языковыми фичами не было, подобные штуки но в других контекстах я уже реализовал и знал все соответствующие технические аспекты, о чём и заявлял ранее.

EP>В осторг же связан с тем что я получил ровно то что и что и планировал изначально — идентичный ассемблерный код, ибо это самая красноречивая манифестация zero overhead, позволяющая на корню отсечь все кривотолки.

Так ты определись, или восторг по причине полезности, или по причине очередной победы над языком.
Если восторг про полезность, поделись выкладками, из которых следует эта полезность. Zero Overhead тянет только на победу над языком.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>В тестах выше как раз аналогичные накладные расходы и измерялись — быстрая ручная версия против аналогичной на DSL.
EP>Какой ещё перекомпиляции?
Вот именно, ты даже не представляешь от чего быстродействие запросов зависит, но пытаешься спорить. Это у всех C++ников такая черта?

G>>>>Теперь покажи то, что делает linq.
EP>>>Ну конечно, начинается, как я и говорил
G>>Так ты не показал. Ключевая фича linq — конструирование запросов из кусков. У тебя нет такого конструирования, потому что у тебя даже дважды where написать нельзя.
G>>Ты все пытаешься свести к статическим запросам,
EP>Про динамичные я уже выше говорил с IT. Тебя что конкретно интересует?
Ответ на мой вопрос.

G>>а они ничем не лучше, чем написанные руками. Ты это показал. Только написанные руками понятнее.

EP>А как же "главный козырь"?
EP>

IT>>Ну и под конец главный козырь LINQ — type safety. Можете мне петь любые песни про любые тормоза, но это преимущество ни много ни мало переводит работу с БД на принципиально другой уровень.

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

G>>>>Для затравки:
G>>>>

G>>>>IQueryable<Foo> F(IQueryable<Foo> q, int? v) => v.HasValue ? q.Where(x => x.value == v) : q
G>>>>

EP>>>Пример чего? Полностью динамических запросов или комбинаторики? Полностью динамические запросы есть в примерах sqlpp11.
EP>>>...
G>>Они не полностью динамические
EP>Почему? Что по твоему мешает их сделать таковыми?
Нормального способа сделать функцию как выше — нету. В первую очередь мешает отсутствие IQueryable.


G>>Функция, которая накладывает такой предикат должна работать с любым IQueryable<Foo>, независимо от того какие предикаты были на него наложены.
EP>Причём тут любой "IQueryable"? В C++ другие техники.
Так покажи их. Самое главное чтобы функцию не пришлось дублировать для каждого типа. Особенно с учетом, что у тебя добавятся group by, join и возможно другие предложения.

EP>>>Декомпозиция/композиция при конкретных типах есть.
EP>>>Если ты чего-то не понимаешь, то не надо додумывать что тебе хочется и утверждать это как факт — лучше спроси про непонятные места
G>>Нельзя написать from(t).where(x).where(y) чтобы это потом склеилось в нормальный запрос.

EP>В первом примере нельзя, так как я посчитал это не нужным, ибо и так очевидно
EP>А вот во втором примере как раз такая конструкция и поддерживается. Ты совсем не смотрел пример из сообщения на которое отвечаешь? Главное писать, да?
EP>

EP>select foo.value, foo.id, foo.number from foo where number>12 and value>21 and id>32 
EP>

Сорри, когда копипастил скушал часть. Имел ввиду такое выражение from(t).where(x).select(y).where(z)

Здравствуйте, gandjustas, Вы писали:

EP>>Какой ещё перекомпиляции?
G>Вот именно, ты даже не представляешь от чего быстродействие запросов зависит, но пытаешься спорить. Это у всех C++ников такая черта?

Не, это не у С++ников, это у тех у кого познания в РСУБД не ушли дальше написания несложных запросов.

Здравствуйте, gandjustas, Вы писали:

G>>>В твоем варианте накладные расходы от перекомпиляции непараметризованных запросов превысят любые экономии на склейке строк.
EP>>Какой ещё перекомпиляции?
G>Вот именно, ты даже не представляешь от чего быстродействие запросов зависит, но пытаешься спорить. Это у всех C++ников такая черта?

Ты не кривляйся, а отвечай по существу. Если ты про параметризацию, то я тебе отвечал в другом сообщении что её не трудно добавить, и на дискуссию это никак не влияет, но чтобы придраться и передёрнуть — да, вполне сойдёт

G>>>>>Теперь покажи то, что делает linq.
EP>>>>Ну конечно, начинается, как я и говорил
G>>>Так ты не показал. Ключевая фича linq — конструирование запросов из кусков. У тебя нет такого конструирования, потому что у тебя даже дважды where написать нельзя.
G>>>Ты все пытаешься свести к статическим запросам,
EP>>Про динамичные я уже выше говорил с IT. Тебя что конкретно интересует?
G>Ответ на мой вопрос.

На какой вопрос? Про "дважды where" уже ответил.
К статическим "всё свести" не пытаюсь. Там где много динамики, очевидно нужна динамика, а не комбинаторный взрыв. О чём и говорил ранее:

IT>>Например, поисковые формы. Есть 50 колонок для фильтрации запроса, а в результирующем гриде есть возможность выбирать отображаемые колонки. Под фильтрацией понимается не только фильтрация колонок в мастер таблице, но и фильтрация по колонкам связанных таблиц.
EP>Да, тут динамика, причём здесь предварительно генерировать все варианты не разумно, ибо их очень много.

G>>>а они ничем не лучше, чем написанные руками. Ты это показал. Только написанные руками понятнее.
EP>>А как же "главный козырь"?
G>Это по сравнению с ручной склейкой строк.

А в выделенном ты про что говорил? "написанные руками" это ты про какие?

G>Потому что каждый разработчик, который хоть немного в курсе как работают, знает что для быстрой работы одними статическими запросами не обойдешься.

А я этого не утверждал Что же вы все пытаетесь приписать мне то, чего я не говорил Вот например что я говорил выше:

EP>>>Такие запросы тоже можно сгенерировать во время компиляции — вопрос в количестве вариантов.
IT>>В этом нет смысла. Единственная проблема ET — это сложность получения хешь функции самого дерева, т.к. оно перестраивается компилятором при каждом вызове. Если делать свой собственный DSL, то такую возможность можно предусмотреть и тогда проблема кеширования запросов отпадает. Т.е. не стоит выпрыгивать из штанов в compile-time, получая неполноценный результат.
EP>Не спорю, возможно и не стоит.
EP>Я лишь говорю о том, что многие преимущества linq, в том числе и то что ты называешь главным козырем — type-safety, можно получить через генерацию compile-time, даже для динамических запросов. Насколько же это целесообразно — отдельный и важный вопрос.

G>>>Они не полностью динамические
EP>>Почему? Что по твоему мешает их сделать таковыми?
G>Нормального способа сделать функцию как выше — нету. В первую очередь мешает отсутствие IQueryable.

Допустим нужен аналог IQueryable, что по твоему мешает его реализовать?

G>>>Функция, которая накладывает такой предикат должна работать с любым IQueryable<Foo>, независимо от того какие предикаты были на него наложены.
EP>>Причём тут любой "IQueryable"? В C++ другие техники.
G>Так покажи их. Самое главное чтобы функцию не пришлось дублировать для каждого типа.

Какую именно функцию? И где именно дублирование?

G>>>Нельзя написать from(t).where(x).where(y) чтобы это потом склеилось в нормальный запрос.
EP>>В первом примере нельзя, так как я посчитал это не нужным, ибо и так очевидно
EP>>А вот во втором примере как раз такая конструкция и поддерживается. Ты совсем не смотрел пример из сообщения на которое отвечаешь? Главное писать, да?
EP>>

EP>>select foo.value, foo.id, foo.number from foo where number>12 and value>21 and id>32 
EP>>

G>Сорри, когда копипастил скушал часть. Имел ввиду такое выражение from(t).where(x).select(y).where(z)

Это добавляется элементарно, но ты же опять к чему-нибудь придирёшься, да? Мол запрос не параметризованный, после параметризации ещё к чему-нибудь
Я этого не сделал сразу потому что не акцентировал внимание на мощности expression, ибо примеров на это выше крыши

Здравствуйте, Ikemefula, Вы писали:

_>>О, я смотрю это уже становится похоже на реальность (уже 16% накладных расходов), причём на достаточно долгих запросах.
I>Не на реальность, а на синтетику. Это замер обращения к базе через linq. Не забывай смотреть абсолютные цифры — 56 микросекунд на запрос. Типичный http запрос при обработке выполняется на порядки дольше.

Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.

>> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
I>СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.

Ну про цифры мы уже всё выяснили (см. выше)... )))

I>Если ты влупишь СУБД рядом с сервером, то они будут мешать друг другу только самим присутствием — каждому нужны память и кеш процессора. В типичном приложении СУБД обслуживает несколько серверов.

Мешать они конечно же будут, но только в том случае, если приложение будет каким-то кривым (например использующим Linq ). А нормальное приложение, у которого основная задача в конвертации json в sql (мгновенное дело, если не привлекать какой-нибудь там Linq ) и потом результатов снова в json (ну может ещё какая-нибудь аутентификация по кукам в начале), будет большую часть времени банально висеть в ожидание результата из БД.

>>то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...
I>В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.

Бредим? ) Процент накладных расходов не зависит от абсолютного значения нагрузки. О высоконагруженных приложениях тут говорят только потому, что для них это становится уже критично (слишком дорого по деньгам). А проявляется то оно абсолютно везде, просто в большинстве случаев этот факт не принципиален, т.к. требуемое железо адекватно по деньгам.

_>>Так кто там говорил о предельном максимуме расходов в 5%? )
I>Для типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT

О, т.е. теперь ситуация, когда http-демон и БД находятся на одном сервере, — это у нас не типичный сценарий? А как ты думаешь, какой процент веб'а работает по такому сценарию, а какой с разделёнными машинами? )

Кстати, а вот скажем сайт rsdn по твоему на скольких машинах работает? )))

Здравствуйте, gandjustas, Вы писали:

G>>>Иначе уже была бы реализован аналог linq на C++.
EP>>Альтернативы есть, пусть и не 1-в-1 аналогичные по замыслу, но тем не менее. Тот же sqlpp11.
G>Я посмотрел sqlpp11, это даже близко не linq. В нем тупо нет средств комползиции. Это api для более-менее типизированного построения примитивных запросов. Он не может никаким образом получить два разных запроса из одного и того же куска кода. Даже теоретически.

Рассуждения о примитивных запросах очень забавны с учётом того, что в данной темке были представлены примеры sql запросов не записываемых на linq, но при этом не было представлено ни одного sql запроса, которого невозможно записать на sqlpp11.

EP>>EDSL'ей для C++ много разных, в том числе и на тему SQL, метапрограммирование полное по Тьюрингу, есть compile-time обработка и генерация строк — то есть всё необходимое.
G>А linq даже близко нет. Странно, да?
G>С linq решается гораздо более сложная задача, чем edsl или генерация строк из кода.

Это верно. Хотя бы потому что Linq и SQL не эквивалентны и соответственно при записи запросов через Linq требуется не тривиальная трансформация. Только вот кто тебе сказал, что это самый оптимальный способ работы с РСУБД? ) Может быть он такой в .net только потому, что другого эффективного способа записи выражений там просто нет (кстати, а этот способ изначально был создан совсем для работы с БД)? )

Здравствуйте, gandjustas, Вы писали:

G>>>4) Как ты сделаешь провайдеры под разные БД? (на этом alex_public посыпался)
_>>Эээ, что? ) Бредим? ) Если ты говоришь про sqlpp11, то там как раз реализован полноценный механизм провайдеров (там они называются коннекторы), аналогичный подходу в Linq2database (ну за исключением того, что большая часть задач отрабатывает не в рантайме). Более того, данный подход существовал и применялся задолго до рождения linq, так что даже смешно считать это чем характерным только для linq.
G>Мы уже посмотрели твой sqlpp11. Он не умеет генерить разный sql для разных баз. Так что провайдеры\коннекторы даже рядом не валялись с linq2database.
G>sqlpp11 — замена склейки строк для примитивных запросов. Даже джоин с одной и той же таблицей дважды не осилит или джоин с derived table с group by.

Ну раз по твоему не осилит столько всего, то тебя конечно же не затруднит показать конкретный пример sql кода, который не способен сгенерировать sqlpp11? )

А то ведь примеры sql кода, которые не может сгенерировать linq уже демонстрировались... )))

Здравствуйте, IT, Вы писали:

_>>Но я здесь уже демонстрировал, что переход к динамике (т.е. формирования строки запроса в рантайме, в зависимости от каких-то внешних условий) добавляет незначительные временные затраты (в моём тесте речь шла о паре микросекунд), несравнимые с накладными расходами от использования того же linq.
IT>Это практические результаты или теория?

Это результаты измерений в тестах.

Здравствуйте, alex_public, Вы писали:

_>Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.

Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?

>>> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
I>>СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.

_>Ну про цифры мы уже всё выяснили (см. выше)... )))

Да, мы выяснили, что ты по прежнему отказываешься даже признавать наличие самого веб-стека.

_>Мешать они конечно же будут, но только в том случае, если приложение будет каким-то кривым (например использующим Linq ). А нормальное приложение, у которого основная задача в конвертации json в sql (мгновенное дело, если не привлекать какой-нибудь там Linq ) и потом результатов снова в json (ну может ещё какая-нибудь аутентификация по кукам в начале), будет большую часть времени банально висеть в ожидание результата из БД.

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

I>>В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.

_>Бредим? ) Процент накладных расходов не зависит от абсолютного значения нагрузки. О высоконагруженных приложениях тут говорят только потому, что для них это становится уже критично (слишком дорого по деньгам). А проявляется то оно абсолютно везде, просто в большинстве случаев этот факт не принципиален, т.к. требуемое железо адекватно по деньгам.

Я про абсолютное время запроса к бд (на фоне веб-стека). Именно оно определяет, какая будет загрузка системы, потому как количество юзеров каким было, таким и осталось. Стек как работал, так и работает. linq здесь минорный игрок.

>типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT

_>О, т.е. теперь ситуация, когда http-демон и БД находятся на одном сервере, — это у нас не типичный сценарий? А как ты думаешь, какой процент веб'а работает по такому сценарию, а какой с разделёнными машинами? )

Типичный в вебе, типичный в энтерпрайзе, типичный в высоконагруженых — это все очень, очень разное.

Веб, который веб, как раз висит в ожидании ответа БД. Потому непринципиально как долго формируется запрос, милисекунду больше, или милисекунду меньше. Здесь вообще нормой является EF, потому что висение в ожидании все равно перевешивает даже такие тормоза.

_>Кстати, а вот скажем сайт rsdn по твоему на скольких машинах работает? )))

Не в курсе. Пудозреваею, rsdn большей частью висит в ожидании ответа от бд.

Здравствуйте, alex_public, Вы писали:

G>>С linq решается гораздо более сложная задача, чем edsl или генерация строк из кода.

_>Это верно. Хотя бы потому что Linq и SQL не эквивалентны и соответственно при записи запросов через Linq требуется не тривиальная трансформация.

Наоборот, тривиальная. Смотри примеры с пагинацией. Какой код предлагается писать на sqlpp ты так и не показал. Если юзер влупит запрос пагинации в стиле db2, то совершенно ясно, sqlpp не умеет сворачивать такое в структуру для mysql

В случае с linq в дереве выражений явно записаны намерения пользователя.

Здравствуйте, IT, Вы писали:

_>>Склейка строк для реализации динамического запроса может выглядеть так (целиком работающий код можешь глянуть http://rsdn.ru/forum/flame.comp/6433119.1):

Автор: alex_public
Дата: 01.05.16

_>>

_>>if(...) q.where.add(test.fvalue>i);
_>>

IT>Боюсь ты плохо представляешь себе динамику. На деле происходит следующее:
IT>

IT>if (...) q = q.Where(t => t.ParentTable.Field1 == 10);
IT>

IT>ParentTable — это ассоциация, при возникновении которой в запрос нужно срочно добавлять JOIN к ParentTable. Т.е. склейка просто не будет работать. Клеить нужно SQL AST, а уже по нему далее строить SQL.

Хыхы, ты похоже пропустил всё обсуждение. Данные вопросы уже подробно обсасывались прямо в данной темке. Там было продемонстрировано и как это тривиально реализуется на sqlpp11 и почему подход linq сомнителен.

P.S. Могу дать ссылки на соответствующие сообщения в данной темке. Хотя странно это всё конечно, потому как вот прямо за сообщением с обсуждаемым исходником реализации на sqlpp11 идёт твоё сообщение (хотя и не про это), так что по идее ты не мог его не видеть...

Здравствуйте, IT, Вы писали:

_>>Так кто там говорил о предельном максимуме расходов в 5%? )
IT>Ну смотри на результат выше для длинных запросов. Десятые процента

Ну так а с этим разве кто-то спорит? ) Это ты сам себе придумал какое-то утверждение и опровергаешь его.

У меня изначально было всего лишь одно утверждение: на некоторых типах запросов (условно говоря быстрых) накладные расходы от использования linq весьма существенны. Ты с этим не согласился, заявив что накладных расходов более 5% не может быть в принципе. Однако мы видим на многих тестах (в том числе и твоих же собственных!), что это не так и накладные расходы бывают существенно больше.

Вообще ситуация со всеми этими казалось бы произвольными цифрами в тестах достаточно простая. Абсолютное значение накладных расходов от linq можно сказать фиксировано (зависит от структуры запроса, типа СУБД, используемого железа), а абсолютное значение времени итогового запроса естественно не фиксировано (зависит от множества внешних факторов типа количества запрашиваемых строк, количества просматриваемых строк в таблицах, размещения и железа для СУБД и т.п.). Соответственно при желание мы можем подогнать в тестах процент накладных расходов под любую необходимую нам величину, хоть 0,003%, хоть 300%.

Казалось бы такой произвол в измерениях странен. Но он на самом деле отражает вполне очевидный реальный факт: для одних задач использование linq по сути будет бесплатным, а для других задач использование linq будет не желательно — надо смотреть каждый конкретный случай отдельно. Непонятно только одно, почему "фанаты" linq в данной ветке так упорно спорят с этим очевидным фактом.

Здравствуйте, IT, Вы писали:

_>>Гитхаб не репрезентативен, потому что на него не принято выкладываться целым областям индустрии. Кто-нибудь видел там выложенные исходники прошивок микроконтроллеров автомобиля, выкладываемого автоконцернами? Или прошивок для ЧПУ (не домашних поделок, а настоящих) и прочей промышленной автоматизации? )
IT>Можно подумать TIOBI видел много прошивок и энтерпрайз приложений.

Авторы данных продуктов вполне себе общаются на SO, различных конференциях и т.п. А это всё как раз и есть база для подчёта TIOBI.

Здравствуйте, artelk, Вы писали:

IT>>Добавил, начало скакать туда сюда, пришлось увеличить количество итераций и нивелировать порядок выполнения. Получилось так:
IT>>

IT>>LINQ: 1000000 in 00:00:56.0547832
IT>>ADO:  1000000 in 00:00:49.1683344
IT>>SQL:  1000000 in 00:00:48.4624714
IT>>

A>Я правильно подозреваю, в тесте все данные лежали в кэше на субд сервере? В реальности будут чтения с дисков, так что подобные сравнения — это замеры у кого ноль длиннее.

Если ты сделал свои выводы на основание предположения, что 1000000 — это число запросов в тесте, то твои выводы не верны вследствие не верности изначального предположения. )

Здравствуйте, gandjustas, Вы писали:

G>Теперь покажи то, что делает linq.
G>Для затравки:
G>

G>IQueryable<Foo> F(IQueryable<Foo> q, int? v) => v.HasValue ? q.Where(x => x.value == v) : q
G>

G>1) Три разных типа для select, where и from не подойдут, не будет никакой композиции
G>2) Запрос должен быть с параметрами
G>3) Нужно поддерживать nullable

Если использовать sqlpp11, то это будет выглядеть так:

auto F=[](auto& q, optional<int> v) {if(v) q.where.add(Table.value==*v);};

Да, это естественно уже динамика, но с полной статической проверкой типов и при этом по сути не вносящая накладных расходов (относительно соответствующего кода на голых sql строках, который мы считаем минимальный базис). В отличие от Linq. )

Здравствуйте, alex_public, Вы писали:

IT>>ParentTable — это ассоциация, при возникновении которой в запрос нужно срочно добавлять JOIN к ParentTable. Т.е. склейка просто не будет работать. Клеить нужно SQL AST, а уже по нему далее строить SQL.

_>Хыхы, ты похоже пропустил всё обсуждение. Данные вопросы уже подробно обсасывались прямо в данной темке. Там было продемонстрировано и как это тривиально реализуется на sqlpp11 и почему подход linq сомнителен.

Ты не показал, как на sqlpp склеивается два разных AST. Собтсвенно, об этом тебя попросили практически все.

_>P.S. Могу дать ссылки на соответствующие сообщения в данной темке. Хотя странно это всё конечно, потому как вот прямо за сообщением с обсуждаемым исходником реализации на sqlpp11 идёт твоё сообщение (хотя и не про это), так что по идее ты не мог его не видеть...

Набор ифов можешь оставить себе. Флажковое программирование закончилось еще в семидесятых.

Здравствуйте, alex_public, Вы писали:

_>Ну так а с этим разве кто-то спорит? ) Это ты сам себе придумал какое-то утверждение и опровергаешь его.

_>У меня изначально было всего лишь одно утверждение: на некоторых типах запросов (условно говоря быстрых) накладные расходы от использования linq весьма существенны. Ты с этим не согласился, заявив что накладных расходов более 5% не может быть в принципе. Однако мы видим на многих тестах (в том числе и твоих же собственных!), что это не так и накладные расходы бывают существенно больше.

Враньё.Ты утверждал,
1 что издержки настолько высокие, что целый класс приложений невозможно реализовать с таким подходом.
2 в качестве решения, как отказ от linq, ты привел Dapper.

По факту —
1 ты проигнорировал и продолжаешь игнорировать издержки самого веб-стека и некоторых других вещей.
2 Dapper не быстрее честного OR/M.

_>Вообще ситуация со всеми этими казалось бы произвольными цифрами в тестах достаточно простая. Абсолютное значение накладных расходов от linq можно сказать фиксировано (зависит от структуры запроса, типа СУБД, используемого железа), а абсолютное значение времени итогового запроса естественно не фиксировано (зависит от множества внешних факторов типа количества запрашиваемых строк, количества просматриваемых строк в таблицах, размещения и железа для СУБД и т.п.). Соответственно при желание мы можем подогнать в тестах процент накладных расходов под любую необходимую нам величину, хоть 0,003%, хоть 300%.

В том то и дело. Смотреть нужно абсолютны величины, а уже эти абсолютные величины сравнивать с издержками веб-стека.

_>Казалось бы такой произвол в измерениях странен. Но он на самом деле отражает вполне очевидный реальный факт: для одних задач использование linq по сути будет бесплатным, а для других задач использование linq будет не желательно — надо смотреть каждый конкретный случай отдельно. Непонятно только одно, почему "фанаты" linq в данной ветке так упорно спорят с этим очевидным фактом.

Подробнее про эти "другие задачи". Что за они ? С высоконагружеными, энтерпрайз приложениями и веб-приложениям эти "другие задачи" не имеют ничего общего.
1 В высоконагруженых приложениях применяется, в т.ч., тот же более медленный Dapper и это не является проблемой
2 В энтерпрайз типичные запросы строятся динамически и их тысячи
3 в веб приложениях бОльшую часть времени сервер висит на ожидании ответа базы.

Везде, см пп. 1-3 издержки веб-стека много больше издержек на OR/M.

Итак, что это за "другие задачи" ?

Здравствуйте, alex_public, Вы писали:

_>У меня изначально было всего лишь одно утверждение: на некоторых типах запросов (условно говоря быстрых) накладные расходы от использования linq весьма существенны.

Изначально у тебя было такое утверждение:

Вообще это решение достаточно феерично своей кривизной.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, artelk, Вы писали:

A>>Я правильно подозреваю, в тесте все данные лежали в кэше на субд сервере? В реальности будут чтения с дисков, так что подобные сравнения — это замеры у кого ноль длиннее.

_>Если ты сделал свои выводы на основание предположения, что 1000000 — это число запросов в тесте, то твои выводы не верны вследствие не верности изначального предположения. )

Т.е. число roundtrip-ов к базе было даже меньше и влияние латентности сети было меньше?
Так это даже усиливает мое утверждение.