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

V>>Это если не вдаваться в суть написанного.
V>>Там все примеры — по-сути кодогенератор.
НС>Да я понимаю. Речь то не про это, а про полученный результат.

В результате на бинарном протоколе примерно в сто раз меньшее потребление энергии (если прямой речью) при настолько же приятном внешнем использовании.
В том числе заслуга кодогенерирующих if constexpr, уменьшающих частоту сброса конвейеров процов.
В том числе показано сравнение синтаксиса С++03 vs более новых диалектов, где кое-какие навороты сократились до 3-х строк.


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

1. Не реализованы даже те некоторые возможности, которые могли бы быть реализованы на диалекте, скажем, TSQL через батчи с промежуточными переменными.
2. Речь не только про SQL, теоретически есть возможность написать провайдер для сценариев linq to objects, подсунув соотв. контейнеры с подержкой IQueryable, где за счёт кодогенерации поиметь приличный буст на больших О. Потому что встроенный linq 2 objects, мягко говоря, не алё. Периодически его исопльзуем для написания кода, но в процессе профилирования из hot path всегда уходит. (Со своей сетевой либой на .Net Core подошли к 3-6 микросекундам на отклик, что сравнимо с плюсовыми реализациями, но из стандартной либы используется почти ничего, увы, даже парсинг чисел и дат + обратное преобразование в текст свои, бо на каждой такой операции разница в 3-5 раз в сравнении со встроенными даже самими последними реализациями)


НС>Можно, конечно, в памяти досчитывать, что некоторые провайдеры пытаются, но вреда от этого больше чем пользы. Намного правильнее материализовать то что есть, а потом допиливать результат уже обычным linq 2 objects.

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

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

V>>Это если не вдаваться в суть написанного.
V>>Там все примеры — по-сути кодогенератор.
НС>Да я понимаю. Речь то не про это, а про полученный результат.

В результате на бинарном протоколе примерно в сто раз меньшее потребление энергии (если прямой речью) при настолько же приятном внешнем использовании.
В том числе заслуга кодогенерирующих if constexpr, уменьшающих частоту сброса конвейеров процов.
В том числе показано сравнение синтаксиса С++03 vs более новых диалектов, где кое-какие навороты сократились до 3-х строк.


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

1. Не реализованы даже те некоторые возможности, которые могли бы быть реализованы на диалекте, скажем, TSQL через батчи с промежуточными переменными.
2. Речь не только про SQL, теоретически есть возможность написать провайдер для сценариев linq to objects, подсунув соотв. контейнеры с подержкой IQueryable, где за счёт кодогенерации поиметь приличный буст на больших О. Потому что встроенный linq 2 objects, мягко говоря, не алё. Периодически его используем для написания кода, но в процессе профилирования из hot path всегда уходит. (Со своей сетевой либой на .Net Core подошли к 3-6 микросекундам на отклик, что сравнимо с плюсовыми реализациями, но из стандартной либы используется почти ничего, увы, даже парсинг чисел и дат + обратное преобразование в текст свои, бо на каждой такой операции разница в 3-5 раз в сравнении со встроенными даже самыми последними реализациями)


НС>Можно, конечно, в памяти досчитывать, что некоторые провайдеры пытаются, но вреда от этого больше чем пользы. Намного правильнее материализовать то что есть, а потом допиливать результат уже обычным linq 2 objects.

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