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

I>>В некоторых, крайне редких, когда база находится тут же в памяти того же процесса.

_>Причём тут процесс? Это вообще неактуально. Речь о времени запроса. Например, если запрашивается что-то простенькое (добываемое прямо из индекса) или даже сложное, но в БД включено кэширование, то результат будет практически мгновенно.

Я именно про время запроса и говорю. Оно минимально, когда база или её кеш находится в памяти того же процесса. Меньше в принципе невозможно.
К твоему сведению, запрос совсем необязательно будет формироваться при каждом вызове.

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

_>>>Проблема не в том как используют рефлексию в linq, а в том, что её вообще используют. ))) В то время как она не нужна и можно всё сделать во время компиляции.
I>>Всё — нельзя.

_>Это ещё почему? ) Когда-то давно мы писали код типа db("select name from users where id="+id.to_string()). Это можно считать (на самом деле это конечно же не совсем так, но это тема уже совсем другого разговора, o необходимости sql и т.п.) за референсный пример с нулевым оверхедом. Теперь же мы хотим написать что-то вроде db(select(users.name).from(users).where(users.id==id)), чтобы sql запрос был проверен компилятором (плюс ещё несколько бонусов на тему безопасности и оптимизации под конкретные БД).

Ты в скобках сам себе ответил, при чем ажно дважды. Смена провайдера делается хоть в рантайме, хоть как угодно — без перекомпилирования. А в твоем случае придется перекомпилировать приложение, если вместо обычной БД я использую простое хранилище.

>Соответственно, если компилятор будет преобразовывать такой код в элементарное слияние sql строк (как в первом варианте), то можно считать, что мы получаем нулевой оверхед.

Прежде всего — кучу геморроя с деплойментом, да еще " ценой диких извратов внутри библиотеки".

_>Так вот даже C++ с его убогим метапрограммированием уже умеет такое (правда ценой диких извратов внутри библиотеки, но снаружи их всё равно не видно). А уж языки типа D или Nemerle такое вообще элементарно могут.

Такие фокусы, во первых, реализуются с помощью T4 безо всяких извратов, на обычном привычном языке.
Во вторых, эти фокусы _не_ _востребованы_


_>>>"разница в скорости между рефлексией и склейкой голых строк"? ) Это ты где такой чуши набрался? )))
I>>Тебя процитировал

_>Враньё. ) Покажи у меня такой нелепый текст. )

http://rsdn.ru/forum/flame.comp/6387248.1

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

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

_>>Это ещё почему? ) Когда-то давно мы писали код типа db("select name from users where id="+id.to_string()). Это можно считать (на самом деле это конечно же не совсем так, но это тема уже совсем другого разговора, o необходимости sql и т.п.) за референсный пример с нулевым оверхедом. Теперь же мы хотим написать что-то вроде db(select(users.name).from(users).where(users.id==id)), чтобы sql запрос был проверен компилятором (плюс ещё несколько бонусов на тему безопасности и оптимизации под конкретные БД).
I>Ты в скобках сам себе ответил, при чем ажно дважды. Смена провайдера делается хоть в рантайме, хоть как угодно — без перекомпилирования. А в твоем случае придется перекомпилировать приложение, если вместо обычной БД я использую простое хранилище.

Естественно не придётся перекомпилировать. ))) Максимум что потребуется, это один if на всё приложение. Такого типа:

if(...) db=sqlite3::connection();
else if(...) db=mysql::connection();
else if(...) db=postgresql::connection();

_>>Так вот даже C++ с его убогим метапрограммированием уже умеет такое (правда ценой диких извратов внутри библиотеки, но снаружи их всё равно не видно). А уж языки типа D или Nemerle такое вообще элементарно могут.
I>Такие фокусы, во первых, реализуются с помощью T4 безо всяких извратов, на обычном привычном языке.
I>Во вторых, эти фокусы _не_ _востребованы_

Т.е. примеры реализации ты конечно же привести не можешь, потому что "это не нужно", да? ))) Понятно, понятно... )))

Кстати, с учётом новинок в C++, думаю что мы скоро вернёмся к нормальному текстовому заданию sql строк. В стиле db("select name from users where id={id}"). Только вот при этом в процессе компиляции будет происходить полный разбор этой строки, проверка корректности синтаксиса, преобразование переменных и т.п. ))) Это будет уже действительно максимально удобный вариант, получше и существующих библиотек и всяких linq. )))

_>>>>"разница в скорости между рефлексией и склейкой голых строк"? ) Это ты где такой чуши набрался? )))
I>>>Тебя процитировал
_>>Враньё. ) Покажи у меня такой нелепый текст. )
I>http://rsdn.ru/forum/flame.comp/6387248.1

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

Ну и где там про "разницу в скорости между рефлексией и склейкой голых строк"? Если что, при работе linq2sql происходит и рефлексия и склейка строк и ещё куча всего. Так что говорить про разницу между рефлексий и склейкой строк вообще неадекватно, чего я собственно и не делал. ) Рефлексия (и ещё много чего) в случае linq2sql служит чистым оверхедом. )

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

_>Кстати, с учётом новинок в C++, думаю что мы скоро вернёмся к нормальному текстовому заданию sql строк. В стиле db("select name from users where id={id}"). Только вот при этом в процессе компиляции будет происходить полный разбор этой строки, проверка корректности синтаксиса, преобразование переменных и т.п. )))

Практически такой же синтаксис реализуем в C++11

Автор: Evgeny.Panasyuk
Дата: 12.10.14

:

db("select name from users where id={id}", id)

_>Это будет уже действительно максимально удобный вариант, получше и существующих библиотек и всяких linq. )))

Голый SQL это всё же низкий уровень по возможностям, учитывая связи между таблицами можно получить более лаконичный вариант для типичных применений. Это примерно как Access автоматом строил запросы по набору полей из разных таблиц. В том же linq2db что-то подобное реализовано.

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

_>Естественно не придётся перекомпилировать. ))) Максимум что потребуется, это один if на всё приложение. Такого типа:
_>

_>if(...) db=sqlite3::connection();
_>else if(...) db=mysql::connection();
_>else if(...) db=postgresql::connection();
_>

То есть, компилировать на все случаи жизни.

I>>Такие фокусы, во первых, реализуются с помощью T4 безо всяких извратов, на обычном привычном языке.
I>>Во вторых, эти фокусы _не_ _востребованы_

_>Т.е. примеры реализации ты конечно же привести не можешь, потому что "это не нужно", да? ))) Понятно, понятно... )))

А зачем ? Пудозреваю, здесь одно из двух
1 ты намекаешь, что принципиально невозможно сгенерировать SQL на C#
2 не знаешь, что T4 это обычный C# код вызываемый еще до компиляции. В принципе, нет разницы, до компиляции, или во время неё.

_>Кстати, с учётом новинок в C++, думаю что мы скоро вернёмся к нормальному текстовому заданию sql строк. В стиле db("select name from users where id={id}").

Это незачем. Когда понадобится сменить движок базы, ты вспотеешь приседать. Лучше expression tree или полноценное квазицитирование, нежели вот такие приседания.

>Только вот при этом в процессе компиляции будет происходить полный разбор этой строки, проверка корректности синтаксиса, преобразование переменных и т.п. ))) Это будет уже действительно максимально удобный вариант, получше и существующих библиотек и всяких linq. )))

А кто тебе типы будет подсказывать ?

_>>>Враньё. ) Покажи у меня такой нелепый текст. )
I>>http://rsdn.ru/forum/flame.comp/6387248.1

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

_>Ну и где там про "разницу в скорости между рефлексией и склейкой голых строк"? Если что, при работе linq2sql происходит и рефлексия и склейка строк и ещё куча всего. Так что говорить про разницу между рефлексий и склейкой строк вообще неадекватно, чего я собственно и не делал. ) Рефлексия (и ещё много чего) в случае linq2sql служит чистым оверхедом. )

"медленнее склейки голых sql строк в силу лишних накладных расходов на тормозную рефлексию"
То есть, указывается, что склейка голых строк это хорошо, а тормозная рефлексия и является узким местом, следовательно — разница между рефлексией и склейкой голых строк.

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

_>>Это будет уже действительно максимально удобный вариант, получше и существующих библиотек и всяких linq. )))
EP>Голый SQL это всё же низкий уровень по возможностям, учитывая связи между таблицами можно получить более лаконичный вариант для типичных применений. Это примерно как Access автоматом строил запросы по набору полей из разных таблиц. В том же linq2db что-то подобное реализовано.

Ты не внимательно прочитал мой текст. Речь шла не просто про подстановку параметров, а про полный разбор той строки на классы (соответствующие sql) и потом генерацию из этого новой строки (в соответствие с особенностями БД). Последнее уже реализовано я sqlpp11 — осталось только реализовать разбор строки во время компиляции. Кстати, я уже видел подобную работающую реализацию в Rust'е.

Ну а просто sql строка с подстановкой параметров — это конечно же совсем не интересно и уже давно реализовано в той же SOCI. Пусть и не так красиво, как в твоём примере. )

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

I>То есть, компилировать на все случаи жизни.

А ты думаешь твой ORM в .net по другому устроен? ))) Всё тоже самое. )

_>>Т.е. примеры реализации ты конечно же привести не можешь, потому что "это не нужно", да? ))) Понятно, понятно... )))
I>А зачем ? Пудозреваю, здесь одно из двух
I>1 ты намекаешь, что принципиально невозможно сгенерировать SQL на C#
I>2 не знаешь, что T4 это обычный C# код вызываемый еще до компиляции. В принципе, нет разницы, до компиляции, или во время неё.

Я в курсе, что t4 — это препроцессор в C#. И кстати говоря, меня бы вполне устроило решение на нём, если бы оно могло чётко проверять sql синтаксис и генерировать оптимальные sql строки. Только вот я что-то сомневаюсь, что такое просто написать. И думаю, что готовых реализаций просто нет.

_>>Кстати, с учётом новинок в C++, думаю что мы скоро вернёмся к нормальному текстовому заданию sql строк. В стиле db("select name from users where id={id}").
I>Это незачем. Когда понадобится сменить движок базы, ты вспотеешь приседать. Лучше expression tree или полноценное квазицитирование, нежели вот такие приседания.

Ты видимо тоже невнимательно читаешь. )))

>>Только вот при этом в процессе компиляции будет происходить полный разбор этой строки, проверка корректности синтаксиса, преобразование переменных и т.п. ))) Это будет уже действительно максимально удобный вариант, получше и существующих библиотек и всяких linq. )))
I>А кто тебе типы будет подсказывать ?

Нуу это вообще смешной вопрос. ))) Если уж printf типизированный давно существует в современном C++, то тут уже понятно всё. )

_>>Ну и где там про "разницу в скорости между рефлексией и склейкой голых строк"? Если что, при работе linq2sql происходит и рефлексия и склейка строк и ещё куча всего. Так что говорить про разницу между рефлексий и склейкой строк вообще неадекватно, чего я собственно и не делал. ) Рефлексия (и ещё много чего) в случае linq2sql служит чистым оверхедом. )
I>"медленнее склейки голых sql строк в силу лишних накладных расходов на тормозную рефлексию"
I>То есть, указывается, что склейка голых строк это хорошо, а тормозная рефлексия и является узким местом, следовательно — разница между рефлексией и склейкой голых строк.

ОК, будем считать, что ты плохо понял мою фразу. ) Очевидно, что время работы рефлексии никто не сравнивает со временем склейки голых строк. Её сравнивают с нулём, т.е. всё её время — это чистый оверхед.

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

_>Ты не внимательно прочитал мой текст. Речь шла не просто про подстановку параметров, а про полный разбор той строки на классы (соответствующие sql) и потом генерацию из этого новой строки (в соответствие с особенностями БД). Последнее уже реализовано я sqlpp11 — осталось только реализовать разбор строки во время компиляции.

Я всё же понял о чём ты говоришь, и про проверку синтаксиса, и типизацию и т.п. — то есть считай sqlpp11 только с DSL в строке.
Я о другом — сам уровень SQL (пусть и с кучей статический проверок и т.п.) — он низкий. Более высокий уровень это например возможность написать "select table1.value, table2.something", где между этими таблицами целая цепочка других, а построитель запросов сам автоматом пробросит всю лапшу join'ов и т.п.

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

I>>То есть, компилировать на все случаи жизни.

_>А ты думаешь твой ORM в .net по другому устроен? ))) Всё тоже самое. )

Щаз, компилирует каждый запрос под 100500 всех возможных баз данных и диалектов SQL, ага.

_>>>Т.е. примеры реализации ты конечно же привести не можешь, потому что "это не нужно", да? ))) Понятно, понятно... )))
I>>А зачем ? Пудозреваю, здесь одно из двух
I>>1 ты намекаешь, что принципиально невозможно сгенерировать SQL на C#
I>>2 не знаешь, что T4 это обычный C# код вызываемый еще до компиляции. В принципе, нет разницы, до компиляции, или во время неё.

_>Я в курсе, что t4 — это препроцессор в C#. И кстати говоря, меня бы вполне устроило решение на нём, если бы оно могло чётко проверять sql синтаксис и генерировать оптимальные sql строки. Только вот я что-то сомневаюсь, что такое просто написать. И думаю, что готовых реализаций просто нет.

Итого — ты сомневаешься, что парсинг и генерация sql это решаемые задачи. Вопрос — при чем здесь C# и чем здесь С++ принципиально лучше ? Сам подумай — в рантайме можно, а в дизайн-тайм нельзя

I>>А кто тебе типы будет подсказывать ?

_>Нуу это вообще смешной вопрос. ))) Если уж printf типизированный давно существует в современном C++, то тут уже понятно всё. )

Нет, не понятно. Ты понамекал и сказал, что все это невозможно в C#

_>ОК, будем считать, что ты плохо понял мою фразу. ) Очевидно, что время работы рефлексии никто не сравнивает со временем склейки голых строк. Её сравнивают с нулём, т.е. всё её время — это чистый оверхед.

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

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

EP>Я всё же понял о чём ты говоришь, и про проверку синтаксиса, и типизацию и т.п. — то есть считай sqlpp11 только с DSL в строке.
EP>Я о другом — сам уровень SQL (пусть и с кучей статический проверок и т.п.) — он низкий. Более высокий уровень это например возможность написать "select table1.value, table2.something", где между этими таблицами целая цепочка других, а построитель запросов сам автоматом пробросит всю лапшу join'ов и т.п.

А ясно, это значит наоборот, я тебя тогда не понял. Теперь понятно о чём ты. Нууу мне кажется, что здесь уже скорее дело вкуса. Лично мне классический sql вполне нравится и я пока не видел стройных концепции для его более высокоуровневой замены. Правда нравится он мне только для работы с БД, а не с коллекциями — вот работать с массивами через sql синтаксис (как предлагается в linq) мне наоборот совсем не по вкусу.

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

_>>А ты думаешь твой ORM в .net по другому устроен? ))) Всё тоже самое. )
I>Щаз, компилирует каждый запрос под 100500 всех возможных баз данных и диалектов SQL, ага.

Причём тут каждый запрос? ) Речь о драйверах к конкретным БД. Что в .net, что в sqlpp11 под каждую БД есть свой драйвер. И соответственно если мы хотим, чтобы наше приложение умело работать со всеми БД, нам требуется скомпилировать их все и вставит в наше приложение.

_>>Я в курсе, что t4 — это препроцессор в C#. И кстати говоря, меня бы вполне устроило решение на нём, если бы оно могло чётко проверять sql синтаксис и генерировать оптимальные sql строки. Только вот я что-то сомневаюсь, что такое просто написать. И думаю, что готовых реализаций просто нет.
I>Итого — ты сомневаешься, что парсинг и генерация sql это решаемые задачи. Вопрос — при чем здесь C# и чем здесь С++ принципиально лучше ? Сам подумай — в рантайме можно, а в дизайн-тайм нельзя

К чему эти теоретически рассуждения? ) Покажи хоть какой-нибудь пример решения. Я то тебе показываю работающие куски кода.

I>>>А кто тебе типы будет подсказывать ?
_>>Нуу это вообще смешной вопрос. ))) Если уж printf типизированный давно существует в современном C++, то тут уже понятно всё. )
I>Нет, не понятно. Ты понамекал и сказал, что все это невозможно в C#

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

_>>ОК, будем считать, что ты плохо понял мою фразу. ) Очевидно, что время работы рефлексии никто не сравнивает со временем склейки голых строк. Её сравнивают с нулём, т.е. всё её время — это чистый оверхед.
I>И это принципиально неверно. Сравнивать нужно со временем типичных запросов, а они никогда нулю равны не бывают.

Всё правильно. Берём оверхед от рефлексии и всего остального и сравниваем со временем выполнения запроса. Если там будут не десятки процентов, то естественно можно наплевать на это всё. Кстати, а ты представляешь сколько на современной БД исполняется запрос вида "select count(*) from users"? ) Даже без кэширования...

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


_>Всё правильно. Берём оверхед от рефлексии и всего остального и сравниваем со временем выполнения запроса. Если там будут не десятки процентов, то естественно можно наплевать на это всё. Кстати, а ты представляешь сколько на современной БД исполняется запрос вида "select count(*) from users"? ) Даже без кэширования...
Where добавь like какой нибудь или or. А то в таблице может хранится счетчик количества записей.
Я думаю, что количество таких бесполезных запросов стремится к 0. А вот запросы с условиями и соединениями как раз большинство.
И время рефлексии меньше чем передача данных по TCP/IP или пайпы между процессами.

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

_>>>А ты думаешь твой ORM в .net по другому устроен? ))) Всё тоже самое. )
I>>Щаз, компилирует каждый запрос под 100500 всех возможных баз данных и диалектов SQL, ага.

_>Причём тут каждый запрос? ) Речь о драйверах к конкретным БД. Что в .net, что в sqlpp11 под каждую БД есть свой драйвер. И соответственно если мы хотим, чтобы наше приложение умело работать со всеми БД, нам требуется скомпилировать их все и вставит в наше приложение.

Неверно. Ощущение, что ты вывалился из машины времени, прилетел из начала 90х.

I>>Итого — ты сомневаешься, что парсинг и генерация sql это решаемые задачи. Вопрос — при чем здесь C# и чем здесь С++ принципиально лучше ? Сам подумай — в рантайме можно, а в дизайн-тайм нельзя

_>К чему эти теоретически рассуждения? ) Покажи хоть какой-нибудь пример решения. Я то тебе показываю работающие куски кода.

Не вижу смысла. Твой поинт пока что такой — в рантайме можно, а тоже самое но в дизайн-тайм — невозможно
До тебя почему то не доходит, что дизайнт-тайм это тот же рантайм, только в другом приложении.
Включи логирование запросов, увидишь, что нет никакой магии. Все что нужно — сохранить эти запросы, они уже сгенерены, провалидированы и тд и тд.

I>>Нет, не понятно. Ты понамекал и сказал, что все это невозможно в C#

_>Невозможно в C# на этапе компиляции (если не считать варианта с препроцессором, но про такое я вообще не слышал). В рантайме естественно без проблем, но это уже куча оверхеда.

Неинтересно обсуждать особенности твоего восприятия.

_>Всё правильно. Берём оверхед от рефлексии и всего остального и сравниваем со временем выполнения запроса. Если там будут не десятки процентов, то естественно можно наплевать на это всё.

Уже давно посчитали и наплевали.

> Кстати, а ты представляешь сколько на современной БД исполняется запрос вида "select count(*) from users"? ) Даже без кэширования...

Этот запрос есть практически в каждом приложении. Что бы далеко не ходить — открой статистику на рсдн. Она считай вся на таких запросах.

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

_>>Причём тут каждый запрос? ) Речь о драйверах к конкретным БД. Что в .net, что в sqlpp11 под каждую БД есть свой драйвер. И соответственно если мы хотим, чтобы наше приложение умело работать со всеми БД, нам требуется скомпилировать их все и вставит в наше приложение.
I>Неверно. Ощущение, что ты вывалился из машины времени, прилетел из начала 90х.

Ну расскажи, как оно по современному делается. )

_>>К чему эти теоретически рассуждения? ) Покажи хоть какой-нибудь пример решения. Я то тебе показываю работающие куски кода.
I>Не вижу смысла. Твой поинт пока что такой — в рантайме можно, а тоже самое но в дизайн-тайм — невозможно
I>До тебя почему то не доходит, что дизайнт-тайм это тот же рантайм, только в другом приложении.
I>Включи логирование запросов, увидишь, что нет никакой магии. Все что нужно — сохранить эти запросы, они уже сгенерены, провалидированы и тд и тд.

Нет, в результате работы подобного инструмента должны генерироваться не некие готовые строки (это же физически невозможно, т.к. в них в них обычно входят пользовательские данные), а код склейки нескольких строк и параметров из остальной части программы. Естественно такое тоже реализуемо в любом языке с какой-то разновидностью метапрограммирования (сюда можно включить и препроцессоры типа t4), в теории. А вот на практике я про такое слышал в C++, в Rust'е, в D. А вот в C# (t4?) что-то не слышал. )))

_>>Всё правильно. Берём оверхед от рефлексии и всего остального и сравниваем со временем выполнения запроса. Если там будут не десятки процентов, то естественно можно наплевать на это всё.
I>Уже давно посчитали и наплевали.

Ну да, всего то пару ядер процессора сервера займёт и всё. Действительно какие мелочи, просто докупим ещё сервер, если что. )))

>> Кстати, а ты представляешь сколько на современной БД исполняется запрос вида "select count(*) from users"? ) Даже без кэширования...
I>Этот запрос есть практически в каждом приложении. Что бы далеко не ходить — открой статистику на рсдн. Она считай вся на таких запросах.

Верно) Но ты так и не сказал насчёт времени исполнения подобных запросов... )))

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

I>>Неверно. Ощущение, что ты вывалился из машины времени, прилетел из начала 90х.

_>Ну расскажи, как оно по современному делается. )

Драйвера к бд в своём уме никто не компилирует.

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

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

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

I>>Уже давно посчитали и наплевали.

_>Ну да, всего то пару ядер процессора сервера займёт и всё. Действительно какие мелочи, просто докупим ещё сервер, если что. )))

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

>>> Кстати, а ты представляешь сколько на современной БД исполняется запрос вида "select count(*) from users"? ) Даже без кэширования...
I>>Этот запрос есть практически в каждом приложении. Что бы далеко не ходить — открой статистику на рсдн. Она считай вся на таких запросах.

_>Верно) Но ты так и не сказал насчёт времени исполнения подобных запросов... )))

А зачем ? Ты ведь не хочешь ничего читать. Зачем тебе писать ?

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

I>>>Неверно. Ощущение, что ты вывалился из машины времени, прилетел из начала 90х.
_>>Ну расскажи, как оно по современному делается. )
I>Драйвера к бд в своём уме никто не компилирует.

Это не ответ. )

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

Не понял эту твою фразу. Да и вообще уже давно не пойму что ты собственно хочешь доказать. Мы вроде уже давно выяснили, что на нескольких языках (типа C++, Rust, D) имеются подобные (времени компиляции) инструменты. А на C# нет (да и я собственно сомневаюсь, что это адекватно реализуется на T4, вот на Roslyn ещё можно попробовать). Так с чем ты собственно споришь? )

I>>>Уже давно посчитали и наплевали.
_>>Ну да, всего то пару ядер процессора сервера займёт и всё. Действительно какие мелочи, просто докупим ещё сервер, если что. )))
I>Ты намекаешь, что широко известная проблема не имеет решения ? Или люди не в курсе, что она решается ? Или решают и не знают, как именно ?
I>Не пойму, чего ты хочешь сказать.

Да всем понятно как тут и что решается. Если мы пишем дохленький сайтик на .net с парой посетителей в день, то всем глубоко наплевать на этот оверхед, т.к. он никогда не почувствуется. А если ты делаешь на .net (что правда является сомнительной идей на мой вкус, ну да ладно) высоконагруженный сервис с тысячами запросов в секунду или какое-то реалтаймовое решение, в котором актуальны миллисекунды, то просто все эти EF и ему подобные решения на базе Linq выкидываются на помойку и пишется в старых добрых традициях обычный sql код.

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

I>>Драйвера к бд в своём уме никто не компилирует.

_>Это не ответ. )

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

I>>То есть, строки посклеивать можно, а вот отдельно код склейки реализовать нельзя ? Тебе самому не смешно ?

_>Не понял эту твою фразу. Да и вообще уже давно не пойму что ты собственно хочешь доказать. Мы вроде уже давно выяснили, что на нескольких языках (типа C++, Rust, D) имеются подобные (времени компиляции) инструменты. А на C# нет (да и я собственно сомневаюсь, что это адекватно реализуется на T4, вот на Roslyn ещё можно попробовать). Так с чем ты собственно споришь? )

Я как раз и не спорю, а проясняю твою позицию. Не ясно, что значит "адекватно" и тд. Ты расскажи то, какие у тебя страхи, а то ведь непонятно.
А то я вижу твоё выступление примерно так: "На С++ — у-у-у-у! D — а-а-а-а! Rust — o-o-o-o-o! C# — ???"

Чего ты конкретно сказать хотел ?

I>>Не пойму, чего ты хочешь сказать.

_>Да всем понятно как тут и что решается. Если мы пишем дохленький сайтик на .net с парой посетителей в день, то всем глубоко наплевать на этот оверхед, т.к. он никогда не почувствуется. А если ты делаешь на .net (что правда является сомнительной идей на мой вкус, ну да ладно) высоконагруженный сервис с тысячами запросов в секунду или какое-то реалтаймовое решение, в котором актуальны миллисекунды, то просто все эти EF и ему подобные решения на базе Linq выкидываются на помойку и пишется в старых добрых традициях обычный sql код.

То есть, ты сомневаешься что статистика на рсдн сделана через Linq ? Или намекаешь, что команда RSDN раскошелилась на миллион долларов что бы адское железо купить ?
Статистика как раз заработала очень быстро именно когда её на linq перевели.

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

_>>Это не ответ. )
I>Если не веришь, создай дефолтный проект дотнет бизнес веб-приложения в вижле и ткни пальцем в ту часть, где ты видишь компиляцию драйверов.

Ну так они просто уже скомпилированы и подключаются уже в бинарном виде. Собственно и в случае C++ решения всё аналогично. Библиотека sql компилируется один раз и потом подключается готовая во все проекты. Обычно в виде статической библиотеки, т.к. это удобнее. Но можно и динамическую собрать, как в .net. )))

_>>Не понял эту твою фразу. Да и вообще уже давно не пойму что ты собственно хочешь доказать. Мы вроде уже давно выяснили, что на нескольких языках (типа C++, Rust, D) имеются подобные (времени компиляции) инструменты. А на C# нет (да и я собственно сомневаюсь, что это адекватно реализуется на T4, вот на Roslyn ещё можно попробовать). Так с чем ты собственно споришь? )
I>Я как раз и не спорю, а проясняю твою позицию. Не ясно, что значит "адекватно" и тд. Ты расскажи то, какие у тебя страхи, а то ведь непонятно.
I>А то я вижу твоё выступление примерно так: "На С++ — у-у-у-у! D — а-а-а-а! Rust — o-o-o-o-o! C# — ???"
I>Чего ты конкретно сказать хотел ?

Я хотел сказать? ) Это ты начал какие-то разговоры про T4 и т.п.

_>>Да всем понятно как тут и что решается. Если мы пишем дохленький сайтик на .net с парой посетителей в день, то всем глубоко наплевать на этот оверхед, т.к. он никогда не почувствуется. А если ты делаешь на .net (что правда является сомнительной идей на мой вкус, ну да ладно) высоконагруженный сервис с тысячами запросов в секунду или какое-то реалтаймовое решение, в котором актуальны миллисекунды, то просто все эти EF и ему подобные решения на базе Linq выкидываются на помойку и пишется в старых добрых традициях обычный sql код.
I>То есть, ты сомневаешься что статистика на рсдн сделана через Linq ? Или намекаешь, что команда RSDN раскошелилась на миллион долларов что бы адское железо купить ?
I>Статистика как раз заработала очень быстро именно когда её на linq перевели.

Я думаю, что rsdn не является высоконагруженным сервисом. )))

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

_>Да всем понятно как тут и что решается. Если мы пишем дохленький сайтик на .net с парой посетителей в день, то всем глубоко наплевать на этот оверхед, т.к. он никогда не почувствуется. А если ты делаешь на .net (что правда является сомнительной идей на мой вкус, ну да ладно) высоконагруженный сервис с тысячами запросов в секунду или какое-то реалтаймовое решение, в котором актуальны миллисекунды, то просто все эти EF и ему подобные решения на базе Linq выкидываются на помойку и пишется в старых добрых традициях обычный sql код.
Да зря ты так. В теории, конечно всё так, но на практике...
Во-первых, реалтаймовое решение с миллисекундным уровнем не может использовать субд, по крайней мере обычную.
Во-вторых, рефлеския обычно таки быстра, время явно микросекунды, а то и наносекунды. Играет ли это хоть какую-то заментую роль при доступе к БД, где только пинг как минимум 5ms? А возьми тот же rsdn или stackoverflow и время рисования странички ~100ms, получится что эта рефлексия составляет доли процента.
В-третьих, без показаний профайлера разговоры о производительности — как минимум непрофессиональны.

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



_>Да всем понятно как тут и что решается. Если мы пишем дохленький сайтик на .net с парой посетителей в день, то всем глубоко наплевать на этот оверхед, т.к. он никогда не почувствуется. А если ты делаешь на .net (что правда является сомнительной идей на мой вкус, ну да ладно) высоконагруженный сервис с тысячами запросов в секунду или какое-то реалтаймовое решение, в котором актуальны миллисекунды, то просто все эти EF и ему подобные решения на базе Linq выкидываются на помойку и пишется в старых добрых традициях обычный sql код.

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

Для примера вызов нетовского метода из 1С через Ireflect составляет на моем старом ноутбуке 20 000 вызовов в секунду.
http://infostart.ru/public/448668/