Re[114]: Тормознутость и кривость linq - Компьютерные священные войны

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

НС>>Ты вообще читаешь что тебе пишут? Тебе несколько человек уже сказало — никакой рефлексии при обходе дерева нет. Рефлексия используется для анализа типа, описывающего метаданные самой БД. Этот тип в любом linq провайдере анализируется ровно один раз, при первом обращении, потому что типы в дотнете изменяться не могут.

_>А ты что под словом "рефлексия" то понимаешь? ) Похоже что-то своё особое... )))

У него ровно то же, что у и остальных дотнетчиков. А вот что ты имел ввиду — совершенно не ясно.

Цитирую IT, на всякий, если ты пропустил

Совершенно верно. Рефлексия используется для исследования объектов, а не для доступа к ним. Последний провайдер, который использовал доступа объектов был, если мне правильно подсказывает мой склероз, Subsonic. В случаях, когда linq выражение возращает не объект, а используется проекция, runtime рефлексии вообще можно избежать, т.к. компилятор вставляет в выражения токены метаданных, что-то типа methodInfo, fieldInfo, конструкции, которых нет в C#, но есть в CLR.

В общем, насчёт рефлекии можно не париться. Это давным давно решённая проблема.

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

_>А ты что под словом "рефлексия" то понимаешь? ) Похоже что-то своё особое... )))

Это неважно. Важно то, что тех операций, которые дают тормоза там нет.

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

_>На мой вкус для людей знакомых с SQL второй вариант понятнее.

Ага. Тут главное побольше конструкций запихнуть в одну строчку, так круче выглядит.
Для людей, знакомых именно с SQL шарповский query comprehension выглядит однозначно понятнее страшных птичих тропок у тебя.
Ты, кстати, с SQL явно знаком постольку поскольку.

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

I>Те самые 12мс — это именно обращение и передача данных по сети. Кроме того, если ты помнишь, то там даже прямой доступ к бд давал почти те же милисекунды.

По локальной сетке roundtrip пакетов может быть как раз в пределах 10-20 микросекунд.

I>На С++ аналог того самого теста, скажем, через драйвер odbc, не cможет дать меньше чем милисекунды, ну никак.

На небольших базах может и даёт.

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

I>>Те самые 12мс — это именно обращение и передача данных по сети. Кроме того, если ты помнишь, то там даже прямой доступ к бд давал почти те же милисекунды.

V>По локальной сетке roundtrip пакетов может быть как раз в пределах 10-20 микросекунд.

Замеры у alex_public показали что именно столько работает плюсовый код умной склейки строк. Что где может или не может — совершенно неинтересно.
Кстати говоря, я напомню, за тобой должок http://rsdn.ru/forum/flame.comp/6423076

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

V>>По локальной сетке roundtrip пакетов может быть как раз в пределах 10-20 микросекунд.
I>Замеры у alex_public показали что именно столько работает плюсовый код умной склейки строк.

Да, он вышел на порядок "оверхеда" в сравнении с подготовленными заранее строками. Хотя, это какие-от у него запредельные цифры получились. На склейку всех строк при правильном подходе должно уходить от половины до полутора микросекунд от силы. Могу лишь предполагать, что там что-то не так с преобразованием числа в строку.

Например, наши самописные варианты дают чуть ли не в 100 раз большее быстродействие, чем boost::lexical-cast.

I>Что где может или не может — совершенно неинтересно.

Включи внимательность — он прямо давал понять, о чем эти цифры. Когда генерация текста SQL намного меньше времени взаимодействия с базой, то это не принципиально. Но когда одного порядка, как в случае с Linq, то уже ой.

Хотя, мне и 12 ms для linq тоже кажутся чересчур странными на современной-то технике (т.е. хотя бы 5-тилетней давности). Сам-то я не гонял еще linq на предмет производительности, просто любопытно — там действительно такой порядок цифр?

I>Кстати говоря, я напомню, за тобой должок http://rsdn.ru/forum/flame.comp/6423076

Ну я тоже завис там рядом на ожидании ответа от тебя сразу по нескольким сообщениям.

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

I>>Кстати говоря, я напомню, за тобой должок http://rsdn.ru/forum/flame.comp/6423076

V>Ну я тоже завис там рядом на ожидании ответа от тебя сразу по нескольким сообщениям.

Ты не отвлекайся — тема тянется уже три года и у тебя всякий раз находится какое то оправдание.

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

V>>Ну я тоже завис там рядом на ожидании ответа от тебя сразу по нескольким сообщениям.
I>Ты не отвлекайся — тема тянется уже три года и у тебя всякий раз находится какое то оправдание.

Это мне надо или тебе?
Сходил ответил на вопросы к тебе, потом требуешь.
А если оно тебе не надо, то заканчиваешь испытывать терпение коллег.

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

V>>>Ну я тоже завис там рядом на ожидании ответа от тебя сразу по нескольким сообщениям.
I>>Ты не отвлекайся — тема тянется уже три года и у тебя всякий раз находится какое то оправдание.

V>Это мне надо или тебе?

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

V>Сходил ответил на вопросы к тебе, потом требуешь.
V>А если оно тебе не надо, то заканчиваешь испытывать терпение коллег.

Вот-вот, в прошлом году и в позапрошлом ты точно так же увиливал.

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

I>Тебе конечно. Ты сам каждый год проявляешь интерес к той теме и каждый раз сбегаешь

Я не вижу ответов на свои посты и теряю интерес к теме.

I>Вот-вот, в прошлом году и в позапрошлом ты точно так же увиливал.

Дык, не надо быть таким скользким. Одновременно быть громки троллём и тихим убегальщиком в соседских же подветках одной и той же темы и в один и тот же период времени — это надо иметь особый талант.

Тот твой пост я почитал. Ответы были даны заранее. Как и 3 года назад. Ничего не изменилось. Ты нихрена не понимал и сейчас так же воинственно нихрена не понимаешь. Ладно бы тема была еще сложная какая-нить, но речь совсем уж о банальщине. Так шта, опять на эту тему перерыв. Глядишь, к пенсии доберемся. ))

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

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

_>>>Что-то у тебя в двух последовательных фразах прямое противоречие. Так хранимки надо чаще использовать или реже? )))
G>>Надо реже, но заменять их на ручную склейку строк не все хотят. Поэтому Linq выруливает.
G>>Просто запросы в коде приложения без склеек я приравниваю к хранимкам.

_>Пока что в данном конкретном примере как раз вариант со склейкой строк является самым простым и компактным из всех остальных. Соответственно совершенно непонятно почему кто-то предпочитает ему не просто менее оптимальные, но и при этом более громоздкие варианты.
Ты опять рассматриваешь один конкретный пример.
Один конкретных запрос всегда можно написать на SQL даже без склеек.
Но, внезапно, даже в простом в приложении будут сотни запросов, и большая часть из них имеют общие части. Нужен механизм декомпозиции и сборки запросов по частям.
Можно попробовать клеить руками, но в этой теме некорректен каждый второй запрос со склейкой, который ты показываешь.
Поэтому linq выруливает.

_>>>Ну и да, для случая обязательного join решение уже давно было в одном из моих сообщений выше.
G>>Это частное решение для одного запроса. А ты, напомню, обещал универсальное решение, которое сможет генерировать широкий класс таких запросов в compile-time.
_>Что-что я обещал? )
Да, ты собирался показать инструмент не хуже linq, который работает в compile time. А оказывается все что ты можешь показать небольшое улучшение склейки строк без гарантий корректности запросов и без возможности декомпозиции.

_>>>Но вот лично для себя меня этот вопрос всё же заинтересовал, т.к. подобных тестов я что-то не видел (что впрочем не удивительно, учитывая концепцию решения). Всё же интересно о каком порядке величины накладных расходов можно говорить в случае подобной библиотечки. Для проверки этого я набросал простенький тестовый пример для sqlite, работающий на самом базовом уровне (т.е. точно без всяких накладных расходов):
G>>1) Выложи запускаемый код с базой
_>В предыдущем сообщение как раз такой код и был. И можно сказать вместе с базой (она генерируется заново в начале каждого теста).
Где ссылка на github или аналог? Как это собрать? Еще раз — давай компилируемый код, который можно скачать и скомпилировать.

G>>2) Убери select *, если sqlpp не умеет генерировать проекции, то лучше её сразу выкинуть
_>sqlpp умеет всё, что умеет sql. Не больше и не меньше. )
Вот именно, декомпозицию запросов не умеет.

G>>3) Покажи пример с динамически собираемым запросом, с автоматически подставляемыми джоинами. Иначе непонятно чем этот sqlpp лучше склейки строк.
_>Подобный пример был в предыдущих сообщениях в данной теме. Лучше склейки строк естественно статической проверкой корректности синтаксиса sql и независимостью от конкретной СУБД.
Не увидел примера. Ты везде джоины руками выписывал. Покажи как на SQLPP в зависимости от условия добавить джоин и предикат на связанную таблицу без необходимости джоин писать руками.

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

_>>Что-то ты похоже путаешь постоянные соединения и единственное на приложение. Кто тебе мешает иметь постоянное соединение в каждом потоке пула потоков?
S> Из пула соединений ты можешь брать любое соединение в любом потоке. Зачем лишний геморрой привязки к потоку?
S>Ты можешь ограничить количество соединений в пуле

Потому что это оптимальнее. )

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

I>Ога. А ты не забыл, что Питон и Шарп практически эквивалентны в терминах возможностей ?
I>

I>lcd("project")
I>    .mount("-t tmpfs -o size=500M tmpfs /mnt/ramdisk")
I>    .mkdir("/mnt/ramdisk/project")
I>    .cd("/mnt/ramdisk/project"):
I>    .put("Src", "./")
I>    .make("install")
I>    .umount("/mnt/ramdisk");
I>

I>Можно еще и типизировать все параметры, есть куча вариантов, как сделать это просто и качественно с проверкой компилятором всех нюансов.

Ну для начала подобный код не сравним с регулярным (как ты к примеру там вставишь if'ы или for'ы). Но это ещё ерунда (в конце концов можно и на C# сделать некое подобие) по сравнению с главным нюансом. Если ты ещё не понял, то приведённый мною код — это весь скрипт. Теперь ощущаешь разницу? Хотя если ты готов показать мне систему, где приведённый тобой кусок можно сохранить как файл и исполнить, то может ещё и поговорим о сравнение C# и Python для скриптов...

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

S> Не ахти и больше

S>http://ru.stackoverflow.com/questions/496425/%d0%92%d1%85%d0%be%d0%b4-%d0%b2-%d0%b4%d0%b8%d1%80%d0%b5%d0%ba%d1%82%d0%be%d1%80%d0%b8%d1%8e-cd-ssh
S> А так как client.RunCommand возвращающий себя https://www.crestron.com/reference/simpl_sharp/html/M_Crestron_SimplSharp_Ssh_SshClient_RunCommand.htm
S>, то код будет аналогичным

S> Можно сделать Extension методы и полностью получить твой код, даже используя SshClient.
S>Все делается легко и непринужденно.

Ну так покажи пример, сравним) Главное не забудь, что приведённый мною код — это весь скрипт целиком, а не какой-то отрывок из него... )

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

_>>Это ты ответил на вопрос как лучше решить проблему с новыми подключениями на каждый запрос. Но так и не ответил на вопрос чем плохо постоянное подключение.
I>А здесь ничем не отличается от джавы и тд. Держать сетевое соединение слишком дорого, база и сеть тратят на это большие ресурсы. connection pool всего лишь оптимизирует время отклика.

Эээ что? ) Ты где таких фантазий понабрался? )

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

_>>А ты что под словом "рефлексия" то понимаешь? ) Похоже что-то своё особое... )))
НС>Это неважно. Важно то, что тех операций, которые дают тормоза там нет.

Угу, и именно поэтому мы вставляем даже тормозное (потому как хэш от дерева в C# не взять) кэширование, только лишь бы не делать обход дерева при каждом запросе. Ну да, ну да. )))

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

_>>На мой вкус для людей знакомых с SQL второй вариант понятнее.
НС>Ага. Тут главное побольше конструкций запихнуть в одну строчку, так круче выглядит.
НС>Для людей, знакомых именно с SQL шарповский query comprehension выглядит однозначно понятнее страшных птичих тропок у тебя.

Синтаксис без скобочек конечно приятнее. Но ровно до тех пор, пока не оказывается что в ответ на короткое невинное выражение Linq генерирует у себя внутри кучу неявных join или подзапросов. После встречи с таким любой знающий sql предпочтёт поставить лишнее скобочки, но зато хотя бы контролировать реальный итоговый код и видеть его нормальное отображение в исходнике.

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

_>>Пока что в данном конкретном примере как раз вариант со склейкой строк является самым простым и компактным из всех остальных. Соответственно совершенно непонятно почему кто-то предпочитает ему не просто менее оптимальные, но и при этом более громоздкие варианты.
G>Ты опять рассматриваешь один конкретный пример.
G>Один конкретных запрос всегда можно написать на SQL даже без склеек.
G>Но, внезапно, даже в простом в приложении будут сотни запросов, и большая часть из них имеют общие части. Нужен механизм декомпозиции и сборки запросов по частям.

Не обязательно. Если в приложение создан нормальный DAL, то ничего подобного не требуется. Вот для пример глянь скажем сюда (один из самых популярных в мире движков форумов): https://github.com/phpbb/phpbb/tree/3.1.x/phpBB/phpbb/db/driver. Даже на убогом php они спокойно реализовали на голых строках работу с целой кучей СУБД. И код даже не особо страшный (ну насколько это вообще возможно в php).

G>Можно попробовать клеить руками, но в этой теме некорректен каждый второй запрос со склейкой, который ты показываешь.

Все примеры были корректны в контексте дискуссии, как и должно быть у proof of concept. Если же попытаться цепляться к не относящимся к разговору вещам (типа например sql-инъекций и т.п.), как делал один или два присутствующих на форуме неадеквата (давно в игноре у меня), то так можно докатиться до придирок к пунктуации в тексте... И кстати в любом случае это явно сигнализирует о полном отсутствие каких-либо аргументов непосредственно по делу. Мне казалось что ты пока не опускался до такого уровня...

G>Поэтому linq выруливает.

Только в C# и только если не требуется высокая производительность.

G>Да, ты собирался показать инструмент не хуже linq, который работает в compile time. А оказывается все что ты можешь показать небольшое улучшение склейки строк без гарантий корректности запросов и без возможности декомпозиции.

Да, я обещал показать удобную ORM с проверкой синтаксиса запроса на этапе компиляции. И именно это я и показал. Копию Linq никто делать не собирался. Хотя бы потому, что можно сделать лучше (например пойдя путём честного соответствия SQL). Скажем мы уже тут выяснили, что linq orm не умеют работать с предкомпилированными (внутри СУБД) запросами. Думаю, что если начать копать, то ещё много недостатков выяснится. Например, как насчёт CTE и рекурсивных запросов на linq? )

_>>В предыдущем сообщение как раз такой код и был. И можно сказать вместе с базой (она генерируется заново в начале каждого теста).
G>Где ссылка на github или аналог? Как это собрать? Еще раз — давай компилируемый код, который можно скачать и скомпилировать.

Зачем мне гитхаб ради такого? ) Код из сообщения на форуме полностью компилируемый. Что бы его собрать достаточно любого современного компилятора C++, запущенного в командной строке. Плюс к этому необходимо иметь на диске 3 библиотеки: собственно sqlpp11 (не требует сборки — библиотека в заголовочных файлах), sqlite3 (собранная тем же компилятором C++), коннектор (так обзывают тут провайдеров) sqlpp11-sqlite3 (собранная тем же компилятором C/C++). Соответствующие пути к этим библиотекам передаются в качестве параметров в командной строке компилятора (ну у меня это делает специальная автоматическая система сборки, но это не суть). В общем любой знакомый с инфраструктурой C++ легко соберёт код из того сообщения. Если же тебе лично это напряжно, но хочешь сравнить производительность на одной машине, то могу выложить соответствующие exe.

_>>sqlpp умеет всё, что умеет sql. Не больше и не меньше. )
G>Вот именно, декомпозицию запросов не умеет.

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

_>>Подобный пример был в предыдущих сообщениях в данной теме. Лучше склейки строк естественно статической проверкой корректности синтаксиса sql и независимостью от конкретной СУБД.
G>Не увидел примера. Ты везде джоины руками выписывал. Покажи как на SQLPP в зависимости от условия добавить джоин и предикат на связанную таблицу без необходимости джоин писать руками.

А с чего ты взял, что в тексте запроса не должно быть явно указанных join'ов, подзапросов и т.п? )

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	05.05.16 15:58
Оценка:	+1

	От:	Ночной Смотрящий
	Дата:	05.05.16 19:31
	Оценка:

	От:	Ночной Смотрящий
	Дата:	05.05.16 19:38
	Оценка:	+1

	От:	vdimas
	Дата:	05.05.16 21:45
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	06.05.16 11:21
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	07.05.16 18:11
Оценка: