Здравствуйте, alex_public, Вы писали:
_>Эм, под накладными расходами естественно подразумеваются лишние (ненужные для достижения цели) расходы. Если у нас динамический запрос, то очевидно что необходимость его формирования в рантайме — это необходимая задача, так что накладные расходы рассчитываются относительно уже такого кода склейки строк.
Склейка — это круто. Только сначала придётся по ситуации приклеить джоины. А так, да, склейка. linq2db, кстати, в основном занимается склейкой строк. Есть такой класс StringBuilder, предназначен в основном для склейки срок. Склейка — наше всё.
ЗЫ. Я фигею с таких аргументов
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>4) Как ты сделаешь провайдеры под разные БД? (на этом alex_public посыпался)
Эээ, что? ) Бредим? ) Если ты говоришь про sqlpp11, то там как раз реализован полноценный механизм провайдеров (там они называются коннекторы), аналогичный подходу в Linq2database (ну за исключением того, что большая часть задач отрабатывает не в рантайме). Более того, данный подход существовал и применялся задолго до рождения linq, так что даже смешно считать это чем характерным только для linq.
Здравствуйте, alex_public, Вы писали:
_>Если ты готов предоставить другой, более авторитетный источник подобной статистики, то я с удовольствием посмотрю на него и возможно буду пользоваться. Ну а если ты не готов предложить ничего подобного, то тогда твоя критика данного проекта никому не интересна.
Не стоит так тупо копировать аргументы оппонета. Чувак, я же первый определил твой мирок как алтернативный После этого твои намёки смешны
_>Я вот например тоже никогда в жизни не видел разработчика на Кобол (а оно есть в данном рейтинге в первой 20-ке),
Ты их не видел, а у меня 2 или 3 directs — это программисты COBOL. А ещё мне довелось заниматься реверс инжениренгом с COBOL, после чего я обнаружил и идентифицировал мать всех парадигм — флажковое программирование. Flag Injection & flag dependency в полный рост.
_>Что касается VB
Заходи на github и ни одного проекта на VB. С другой стороны насчёт вордов и прочего у меня совершенно нет причин тебе не верить.
IT>>К тому же я ещё не разу не видел, чтобы C# шёл в рост. Он всё время падает с самого свого рождения. Т.е. с самого нуля падает и пока ещё до нуля не упал. Как такое может быть не пойму. Видимо в ваших реальностях это нормально.
_>Ну почему же) Если глянуть сюда http://www.tiobe.com/tiobe_index?page=C%23,
TIOBI о языках программирования — это примерно как censor.net.ua о мировой политике — примерно в тему, но всё мимо.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
I>>Хрен с ней, с этой нечесностью. Сделай, пожалуйста, аналог своего последнего теста только на linq raw sql ? Сильно вопрос интересный, на самом деле. В тестах liiw похоже есть не то косячок, не то они безбожно устарели. Я бы и сам померял, но нынче я в текстовом редакторе считай живу. 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>
О, я смотрю это уже становится похоже на реальность (уже 16% накладных расходов), причём на достаточно долгих запросах. Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере), то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...
Так кто там говорил о предельном максимуме расходов в 5%? )
Здравствуйте, IT, Вы писали:
_>>Эм, под накладными расходами естественно подразумеваются лишние (ненужные для достижения цели) расходы. Если у нас динамический запрос, то очевидно что необходимость его формирования в рантайме — это необходимая задача, так что накладные расходы рассчитываются относительно уже такого кода склейки строк. IT>Склейка — это круто. Только сначала придётся по ситуации приклеить джоины. А так, да, склейка. linq2db, кстати, в основном занимается склейкой строк. Есть такой класс StringBuilder, предназначен в основном для склейки срок. Склейка — наше всё.
И при этом оно замедляет код (по сравнению с полностью статическим запросом) всего на 1-2 микросекунды. Потому что здесь в рантайме происходит исключительно склейка строк и всё. В отличие от Linq, у которого происходит ещё куча всякого ненужного и в итоге накладные расходы в сотни раз больше.
Здравствуйте, IT, Вы писали:
_>>Если ты готов предоставить другой, более авторитетный источник подобной статистики, то я с удовольствием посмотрю на него и возможно буду пользоваться. Ну а если ты не готов предложить ничего подобного, то тогда твоя критика данного проекта никому не интересна. IT>https://www.google.com/search?q=github%20languages%20trends&rct=j
Гитхаб не репрезентативен, потому что на него не принято выкладываться целым областям индустрии. Кто-нибудь видел там выложенные исходники прошивок микроконтроллеров автомобиля, выкладываемого автоконцернами? Или прошивок для ЧПУ (не домашних поделок, а настоящих) и прочей промышленной автоматизации? ) Или наоборот, те же реализации бухгалтерии на VB из Excel'a никогда не попадут на гитхаб. Да даже банально исходников драйверов LTE или видео-кодера там никогда не увидишь, хотя сами драйверы стоят в каждом продаваемом телефоне и их пишет не одна команда программистов (на вполне определённом языке, который соответственно не попадает под статистику гитхаба). Так что статистика гитхаба отражает что угодно, но только не общее состояние индустрии.
_>>Я вот например тоже никогда в жизни не видел разработчика на Кобол (а оно есть в данном рейтинге в первой 20-ке), IT>Ты их не видел, а у меня 2 или 3 directs — это программисты COBOL. А ещё мне довелось заниматься реверс инжениренгом с COBOL, после чего я обнаружил и идентифицировал мать всех парадигм — флажковое программирование. Flag Injection & flag dependency в полный рост.
)))
IT>>>К тому же я ещё не разу не видел, чтобы C# шёл в рост. Он всё время падает с самого свого рождения. Т.е. с самого нуля падает и пока ещё до нуля не упал. Как такое может быть не пойму. Видимо в ваших реальностях это нормально. _>>Ну почему же) Если глянуть сюда http://www.tiobe.com/tiobe_index?page=C%23, IT>TIOBI о языках программирования — это примерно как censor.net.ua о мировой политике — примерно в тему, но всё мимо.
Нуу знаешь, если об их абсолютном позиционирование языков ещё можно поспорить (например по моим субъективным ощущениям JS у них недооценённый, а VB.NET переоценённый), то вот как раз многогодовые тренды по конкретному языку у них очень хорошо отражают реальность. Прямо сразу видны все ключевые события (выходы устройств, стандартов, конкурентов и т.п.).
Здравствуйте, IT, Вы писали:
IT>Отличается от предыдущих тем, что более менее отражает реалии жизни. Во-первых, БД находится на другой машине. Во-вторых, в реальности на ADO.NET так никто не пишет. Ни один вменяемый разработчик не будет использовать индексы вместо имён полей. Такой код живёт ровно до первого изменения.
Непонятно при чём тут ADO.NET который пишется руками за отсутствием других инструментов и сабж.
Для оценки обсуждаемого рантайм оверхеда LINQ нужно сравнивать код с LINQ и такой же код лишь за исключением LINQ. Или например максимально оптимизированный ручной вариант. Но сравнивать с заведомо неоптимальным ручным вариантом это какие-то напёрстки
Здравствуйте, alex_public, Вы писали:
_>>>ОК, тогда всё понятно. ) Значит у тебя просто своя личная альтернативная терминология по этому вопросу. Тогда у нас собственно и нет никакого спора (по терминлогиям споров быть не может — о них просто договариваются и всё). I>>https://www.google.by/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=dapper+micro+orm
_>Так всё же это ORM или нет? ) Или "micro orm" — это у нас теперь не "orm"? ))) Ты уж определись... )))
Здравствуйте, alex_public, Вы писали:
G>>4) Как ты сделаешь провайдеры под разные БД? (на этом alex_public посыпался)
_>Эээ, что? ) Бредим? ) Если ты говоришь про sqlpp11, то там как раз реализован полноценный механизм провайдеров
Полноценного там как раз и нет. sqlpp говорит о том, что транслировать придется sql в sql. Это и есть проблема. Коннектор должен по дереву sql догадаться, что же значат три вложеных запроса, и правильно сгенерировать код в свою базу.
В случае с linq тебе не надо этого делать, ибо в выражении явно указано skip(5).take(20) и можно сразу приступать к генерации
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Непонятно при чём тут ADO.NET который пишется руками за отсутствием других инструментов и сабж. EP>Для оценки обсуждаемого рантайм оверхеда LINQ нужно сравнивать код с LINQ и такой же код лишь за исключением LINQ. Или например максимально оптимизированный ручной вариант. Но сравнивать с заведомо неоптимальным ручным вариантом это какие-то напёрстки
Здесь другая история — скоро 4 месяца как мусолится вполне конкретный набор тестов, в котором, внимание, есть все что ты просишь.
Проблема в том, что интерпретатор не согласен сразу со всеми, включая авторов библиотек
В этом треде нет наверное ни одного дотнетчика, которого бы alex_public не обвинил в некометентности.
Здравствуйте, alex_public, Вы писали:
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>>
_>О, я смотрю это уже становится похоже на реальность (уже 16% накладных расходов), причём на достаточно долгих запросах.
Не на реальность, а на синтетику. Это замер обращения к базе через linq. Не забывай смотреть абсолютные цифры — 56 микросекунд на запрос. Типичный http запрос при обработке выполняется на порядки дольше.
> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
Если ты влупишь СУБД рядом с сервером, то они будут мешать друг другу только самим присутствием — каждому нужны память и кеш процессора. В типичном приложении СУБД обслуживает несколько серверов.
>то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...
В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.
_>Так кто там говорил о предельном максимуме расходов в 5%? )
Для типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>В этом треде нет наверное ни одного дотнетчика, которого бы alex_public не обвинил в некометентности.
EP>А я видел что они его, благо что уехало в мусор:
Это фирменный стиль alex_public — постоянно намякивать на некомпетентность собеседника. Что бы ни обсуждалось — C++, D, Haskell, C#, Linq, Erlang, Python, Java — итог везде одинаковый, при чем независимо от собеседников.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
IT>>Во-вторых, совсем совсем статические запросы — это далеко не все запросы в приложении. EP>Сколько статических по твоим оценкам?
Во многих ERP — близко к нулю. Потому что прикладные запросы как правило достраиваются платформой — добаляется пейджинг, фильтрация, проверка секурности, в том числе row level и т. п.
EP>Я к тому, что если это обусловлено например тем что итоговый запрос собирается в разных частях программы (о чём в этих темах часто и говорят), то для этого динамика не обязательна.
Опять же, во многих ERP части программы могут компилироваться независимо и даже быть от разных поставщиков. Такого чтобы вся ERP система собиралась целиком за раз в одном месте — встречается крайне редко, если вообще встречается.
Здравствуйте, Ночной Смотрящий, Вы писали:
IT>>>Во-вторых, совсем совсем статические запросы — это далеко не все запросы в приложении. EP>>Сколько статических по твоим оценкам? НС>Во многих ERP — близко к нулю. Потому что прикладные запросы как правило достраиваются платформой — добаляется пейджинг, фильтрация, проверка секурности, в том числе row level и т. п.
Это речь опять про декомпозицию?
EP>>Я к тому, что если это обусловлено например тем что итоговый запрос собирается в разных частях программы (о чём в этих темах часто и говорят), то для этого динамика не обязательна. НС>Опять же, во многих ERP части программы могут компилироваться независимо и даже быть от разных поставщиков. Такого чтобы вся ERP система собиралась целиком за раз в одном месте — встречается крайне редко, если вообще встречается.
Ты про многоразовые платформы типа 1С/SAP?
Как оцениваешь процент таких платформ среди всех потребителей СУБД?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это речь опять про декомпозицию?
Нет. Это разные слои приложения как минимум. Про фильтрацию и выюор колонок тебе IT уже написал и ты согласился что это динамика. row level секурность, решенная для общего случая приводит к диким тормозам, поэтому добавляется куча эвристик под конкретный набор прав конкретного пользователя.
НС>>Опять же, во многих ERP части программы могут компилироваться независимо и даже быть от разных поставщиков. Такого чтобы вся ERP система собиралась целиком за раз в одном месте — встречается крайне редко, если вообще встречается. EP>Ты про многоразовые платформы типа 1С/SAP?
Про сотни их.
EP>Как оцениваешь процент таких платформ среди всех потребителей СУБД?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Показывающий что конкретно? Проекции? Фильтры? Автоматические join'ы по связям? G>>Фильтры и проекции, с джоинами потом разберемся EP>То есть после примера с фильтрами и проекциями ты скажешь что мол нет джоинов, того и того, поэтому нещитово и вообще "невозможно"
Сделай хотя бы простой вариант.
EP>>>Это всё ни одна сотня строк кода, реализовать которые мне не интересно. G>>Тогда какой смысл в том, что ты пишешь?
EP>Что значит какой? Я утверждаю что это вполне реализуемо, то есть все технические возможности в наличии. EP>Некоторые же из собравшихся считают что нет, мол проекции не реализуются, статическая декомпозиция "никому не удавалась" — я в ответ показываю конкретные компилируемые примеры.
Ты сейчас апеллируешь к теоретической возможности применить подходы X, Y, Z,... , чтобы получит статическую генерацию.
Хотя никто, в том числе ты, даже X и Y вместе не применял, и не факт, что это вообще получится сделать.
G>>На практике никто такое не сделал, значит невозможно. EP> Нет, не значит, очевидно же.
Очевидно, что нет доказательств, что возможно, только предположение.
Я склонен верить в то, что если что-то не случается на практике, то это невозможно, даже если теоретически может быть.
G>>Иначе уже была бы реализован аналог linq на C++. EP>Альтернативы есть, пусть и не 1-в-1 аналогичные по замыслу, но тем не менее. Тот же sqlpp11.
Я посмотрел sqlpp11, это даже близко не linq. В нем тупо нет средств комползиции. Это api для более-менее типизированного построения примитивных запросов. Он не может никаким образом получить два разных запроса из одного и того же куска кода. Даже теоретически.
G>>>>Потому что построить дерево на шаблонах несложно. Самое интересное начинается дальше. EP>>>Что именно тебя смущает? Говори конкретный аспект и я расскажу (и возможно покажу) каким образом он реализуется G>>Меня смущает, что ты каждый раз даешь пример одного аспекта, а не все вместе. EP>Потому что это требует меньше времени на реализацию, и является ответом на конкретное сомнение, например как в случае с проекциями.
Я понимаю почему ты так пишешь, я также понимаю, что нет гарантии, что можно два твоих примера объединить в один рабочий.
G>>Похоже что все вместе не взлетит от слова вообще. EP>EDSL'ей для C++ много разных, в том числе и на тему SQL, метапрограммирование полное по Тьюрингу, есть compile-time обработка и генерация строк — то есть всё необходимое.
А linq даже близко нет. Странно, да?
С linq решается гораздо более сложная задача, чем edsl или генерация строк из кода.
G>>>>Кроме того сразу видна проблема. У тебя слишком коноетный тип EP>>>Это плата за статику. G>>И как будешь разруливать? EP>Разруливать что именно?
То что типы у тебя слшиком конкретные, а комбинаторы наоборот должны работать с наиболее общими типами. where должен применяться и к from, и к select и к еще куче всяких других типов.
EP>>>Пример на эту тему я уже показал выше
. G>>Ты предлагаешь писать свой where к каждому типу? G>>Это неживая идея изначально.
EP>В каком смысле "к каждому"?
У тебя where находится в структуре Foo, в реальности у тебя вместо Foo будут from, where,select,groupby и набор таких типов может расширяться. При текущей реализации придется where выписывать в каждом типе.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>4) Как ты сделаешь провайдеры под разные БД? (на этом alex_public посыпался)
_>Эээ, что? ) Бредим? ) Если ты говоришь про sqlpp11, то там как раз реализован полноценный механизм провайдеров (там они называются коннекторы), аналогичный подходу в Linq2database (ну за исключением того, что большая часть задач отрабатывает не в рантайме). Более того, данный подход существовал и применялся задолго до рождения linq, так что даже смешно считать это чем характерным только для linq.
Мы уже посмотрели твой sqlpp11. Он не умеет генерить разный sql для разных баз. Так что провайдеры\коннекторы даже рядом не валялись с linq2database.
sqlpp11 — замена склейки строк для примитивных запросов. Даже джоин с одной и той же таблицей дважды не осилит или джоин с derived table с group by.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Это речь опять про декомпозицию? НС>Нет. Это разные слои приложения как минимум.
И что из того что слои?
НС>Про фильтрацию и выюор колонок тебе IT уже написал и ты согласился что это динамика.
Он конкретно сказал про грид с 50-ю опциональными колонками и т.п.
Ты же говоришь про "достраиваются платформой" — то есть мол запрос размазан по разным частям приложения — это может быть как статикой, так и динамикой, в зависимости от использования.
EP>>Ты про многоразовые платформы типа 1С/SAP? НС>Про сотни их. EP>>Как оцениваешь процент таких платформ среди всех потребителей СУБД? НС>А ты?
Я думаю что многоразовых платформ намного меньше чем конечных приложений, причём не важно что там — ERP или что-либо другое.
Здравствуйте, gandjustas, Вы писали:
_>>Эээ, что? ) Бредим? ) Если ты говоришь про sqlpp11, то там как раз реализован полноценный механизм провайдеров (там они называются коннекторы), аналогичный подходу в Linq2database (ну за исключением того, что большая часть задач отрабатывает не в рантайме). Более того, данный подход существовал и применялся задолго до рождения linq, так что даже смешно считать это чем характерным только для linq. G>Мы уже посмотрели твой sqlpp11. Он не умеет генерить разный sql для разных баз.
В каком смысле не умеет? Пиши свой коннектор, и генерируй какой угодно запрос. Там например есть пример коннектора к обычным контейнерам.
Если нам не помогут, то мы тоже никого не пощадим.
После этого твои намёки смешны 
Нет, не значит, очевидно же.