Здравствуйте, Serginio1, Вы писали:
EP>>>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели. S>>>Если потокобезопасная то S>>>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php EP>>Какая из них конкретно? S> Бери какой хочешь. Для этого нужно знать, что ты под std::deque
Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией.
S>>>Ну есть и непотокобезопасные EP>>В той теме так и не привели. S> Ты на год посмотри 30.06.04 S>Тогда мало чего было. Еще Net 1.1 был без дженериков итд.
Я про тему на которую сам дал ссылку.
EP>>>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free." EP>>>>Там сказано что она lock/wait-free? S>>> В фоновом режиме для прохода по графу нет никаких блокировок. EP>>А что ты понимаешь под блокировкой? Stop-the-world? EP>>Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных. EP>>Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано. S> Там может быть куча стратегий. Суть в том, что с каждой новой версией GC работает все быстрее. Если раньше были видны тормоза, то сейчас об этом все забыли
Понятное дело, это видно в том числе и в моём тесте. Но я-то говорил про конкретный аспект.
EP>>>Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11. S>>А в Net это встроено в платформу.
EP>Так это известная тема — вместо предоставления какой-то универсальной возможности, на C# решают какой-то сиюминутный use-case. Это приводит например к зоопарку с вариантами замыканий, которые даже ещё планируют расширять локальными методами. Также это приводит к меньшей гибкости самого языка — шаг влево/вправо — и упираешься в забор: 1
.
Для многих вещей существуют T4 или Nemerle в руки. Было бы желание. Либо функциональщину с карированием итд которая тоже в Net есть, а их использовать уже в C#. На самом деле важные фичи добавляются. И язык развивается. А для среднестатистического программиста как я возможностей выше крыши. Просто такие извращения появляются у С++ которые хотят перенести технику шаблонов перенести на язык которых их не поддерживает. И Слава КПСС
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели. S>>>>Если потокобезопасная то S>>>>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php EP>>>Какая из них конкретно? S>> Бери какой хочешь. Для этого нужно знать, что ты под std::deque
EP>Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией.
S>>>>Ну есть и непотокобезопасные EP>>>В той теме так и не привели. S>> Ты на год посмотри 30.06.04 S>>Тогда мало чего было. Еще Net 1.1 был без дженериков итд.
EP>Я про тему на которую сам дал ссылку.
EP>>>>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free." EP>>>>>Там сказано что она lock/wait-free? S>>>> В фоновом режиме для прохода по графу нет никаких блокировок. EP>>>А что ты понимаешь под блокировкой? Stop-the-world? EP>>>Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных. EP>>>Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано. S>> Там может быть куча стратегий. Суть в том, что с каждой новой версией GC работает все быстрее. Если раньше были видны тормоза, то сейчас об этом все забыли
EP>Понятное дело, это видно в том числе и в моём тесте. Но я-то говорил про конкретный аспект.
Ты не забывай, что с 1С ником разговариваешь. C# для меня хобби. Тем более я не знаю какой сейчас алгоритм сборки мусораэ
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
EP>>Так это известная тема — вместо предоставления какой-то универсальной возможности, на C# решают какой-то сиюминутный use-case. Это приводит например к зоопарку с вариантами замыканий, которые даже ещё планируют расширять локальными методами. Также это приводит к меньшей гибкости самого языка — шаг влево/вправо — и упираешься в забор: 1
О, пошла кодогенерация в ход Да она расширяет возможности, и доступна в том числе и для C++, причём без зацикленности на T4.
Тем не менее, доступность возможности из самого языка, а не системы сборки — это на порядки проще и удобнее.
Например тот же not_null
— попробуй их заменить через T4.
S>Было бы желание. Либо функциональщину с карированием итд которая тоже в Net есть, а их использовать уже в C#. На самом деле важные фичи добавляются. И язык развивается. А для среднестатистического программиста как я возможностей выше крыши. Просто такие извращения появляются у С++ которые хотят перенести технику шаблонов перенести на язык которых их не поддерживает. И Слава КПСС
Тот же not_null помог бы вполне рядовому программисту. Но приходится ждать добавления фичи в язык, а не просто взять готовую библиотечную реализацию, или даже реализовать самому.
Non-nullability checks have to be manually encoded hundreds of times in any large real-world project, and they are not compile-time-enforced.
Здравствуйте, Serginio1, Вы писали:
EP>>Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией. S>Ну например можно такой http://rsdn.ru/forum/src/450320.1
Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать.
Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь.
S> Ты не забывай, что с 1С ником разговариваешь. C# для меня хобби. Тем более я не знаю какой сейчас алгоритм сборки мусораэ
Здравствуйте, Klikujiskaaan, Вы писали:
_>>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально... K>Ну ка расскажи, как ты динамические запросы формируешь на этапе компиляции?
Что ты подразумеваешь под динамическими запросами? )
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.
Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией. S>>Ну например можно такой http://rsdn.ru/forum/src/450320.1
EP>Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать. EP>Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь.
На самом деле в Net много чего нет. Тех же Б+ деревьев S>> Ты не забывай, что с 1С ником разговариваешь. C# для меня хобби. Тем более я не знаю какой сейчас алгоритм сборки мусораэ
EP>Так 1С-ники ведь разные бывают
и солнце б утром не вставало, когда бы не было меня
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.
По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.
_>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.
Здравствуйте, Serginio1, Вы писали:
EP>>Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать. EP>>Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь. S> На самом деле в Net много чего нет. Тех же Б+ деревьев
Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать. EP>>>Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь. S>> На самом деле в Net много чего нет. Тех же Б+ деревьев
EP>Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней.
Не совсем http://rsdn.ru/article/alg/tlsd.xml
Здравствуйте, Serginio1, Вы писали:
EP>>Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней. S>Не совсем http://rsdn.ru/article/alg/tlsd.xml
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF. S> По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.
Ну так миллисекунды — это как раз совсем печально. Скажем если запрос к БД у нас будет исполняться тоже несколько миллисекунд (абсолютно реальный сценарий с современными СУБД), то это означает 50% потери производительности. Ведь в этом случае код на C# будет заниматься никчемной деятельностью (подготовкой к запросу) столько же, сколько и сам запрос. В аналогичном же коде на C++ у нас будет 0 секунд на подготовку запроса (т.е. как при рукопашном коде с зашитой sql строкой). )
В общем делать высоконагруженный сервис с помощью такой хреновины мягко говоря не разумно. )))
_>>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде. S>Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx
Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.
_>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.
Ну не такие они и страшные и неудобные. Если хочешь скорости то написать 2 лишние строчки не проблема.
Зато боддержка нотификаций, слежение за изменениями. Ты не забывай, что это может вставляться в разные гриды итд
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней. S>>Не совсем http://rsdn.ru/article/alg/tlsd.xml
S>>Внизу результаты
EP>Преимущества B+ я понимаю. Но тут же речь не о лучше/хуже, а о том что можно нарваться на Out of Memory на ровном месте.
На самом деле вариантов работы с такими объемами очень редки.
Читаем здесь http://habrahabr.ru/post/149584/
Что же насчет Large Object Heap? Она никогда не дефрагментируется (почти никогда). Это потребовало бы большое количество времени, что может сказаться плохо на работе приложения. Однако это не значит, что CLR начинает потреблять все больше и больше памяти просто так. Во время Full-GC (Gen0, Gen1, Gen2) система все же возвращает ОС память, освобождаясь от уже мертвых объектами из LOH (или дефрагментацией SOH).
Также CLR располагает новые объекты в LOH не только один за другим, как в SOH, например, но и на местах уже свободной памяти, не дожидаясь Full-GC.
Запуск GC не детерминирован, за исключением вызова метода GC.Collect().
Однако все же существуют приблизительные критерии, по которым можно это предсказать (следует помнить, что нижеперечисленные условия приблизительны и CLR сама приспосабливается к поведению приложения, многое еще зависит и от вида сборщика мусора):
•При достижении поколения Gen0 размера в 256 KB
•При достижении поколения Gen1 размера в 2 MB
•При достижении поколения Gen2 размера в 10 MB
Также сборка мусора запускается при нехватке системой памяти. CLR для этого использует Win32-функции CreateMemoryResourceNotification и QueryMemoryResourceNotification.
и солнце б утром не вставало, когда бы не было меня
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF. S>> По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.
_>Ну так миллисекунды — это как раз совсем печально. Скажем если запрос к БД у нас будет исполняться тоже несколько миллисекунд (абсолютно реальный сценарий с современными СУБД), то это означает 50% потери производительности. Ведь в этом случае код на C# будет заниматься никчемной деятельностью (подготовкой к запросу) столько же, сколько и сам запрос. В аналогичном же коде на C++ у нас будет 0 секунд на подготовку запроса (т.е. как при рукопашном коде с зашитой sql строкой). )
_>В общем делать высоконагруженный сервис с помощью такой хреновины мягко говоря не разумно. )))
разумно предварительно скомпилировав часто используемые запросы. Не вижу проблем.
А запрос обычно выполняется значительно дольше. Даже просто перекачка данных по сети.
_>>>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде. S>>Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx
_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.
Если не нравится голый ADO в руки или предварительная компиляция. Каждый выбирает для себя.
Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.
и солнце б утром не вставало, когда бы не было меня
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF. S>> По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.
_>Ну так миллисекунды — это как раз совсем печально. Скажем если запрос к БД у нас будет исполняться тоже несколько миллисекунд (абсолютно реальный сценарий с современными СУБД), то это означает 50% потери производительности. Ведь в этом случае код на C# будет заниматься никчемной деятельностью (подготовкой к запросу) столько же, сколько и сам запрос. В аналогичном же коде на C++ у нас будет 0 секунд на подготовку запроса (т.е. как при рукопашном коде с зашитой sql строкой). )
_>В общем делать высоконагруженный сервис с помощью такой хреновины мягко говоря не разумно. )))
_>>>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде. S>>Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx
_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.
Начиная с версии 4.5 платформы .NET Framework, запросы LINQ кэшируются автоматически. Тем не менее можно использовать скомпилированные запросы LINQ для снижения затрат при последующем выполнении, и скомпилированные запросы могут быть более эффективными, чем запросы LINQ, которые автоматически сохраняются в кэше. Обратите внимание, что запросы LINQ to Entities, которые применяют оператор Enumerable.Contains к коллекции в памяти, автоматически не кэшируются. Также в скомпилированных запросах LINQ не допускаются коллекции в памяти с параметрами.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Сравниваем. Вариант Boost.Range: EP>1. Лаконичнее, красивее.
А всякие _1 это полагаю эталон красоты ? А если надо сравнивать не с константой ?
EP>2. Быстрее. Там под копотом кстати те самые итераторы.
Для ленивого кода — даже не смешно.
EP>3. Выдаёт bidirectional последовательность вместо forward/single pass.
Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007.
Бидирекшинал это очень жосткое органичение само по себе.
Здравствуйте, alex_public, Вы писали:
_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.
Кстати а как заранее компилировать такие запросы
public IQueryable<TEntity> НайтиПоВхождениюВНаименование<TEntity>(paramsstring[] keywords) where TEntity : СправочникПредок
{
var predicate = PredicateBuilder.False<TEntity>();
foreach (string keyword in keywords)
{
string temp = keyword;
predicate = predicate.Or(p => p.Наименование.Contains(temp));
}
return this.Set<TEntity>().AsExpandable().Where(predicate);
}
И использовать
var бд = Константы1С.ГлобальныйКонтекст.БД;
var запрос = бд.НайтиПоВхождениюВНаименование<Справочник.Номенклатура>("Linq", "Наше", "Все").Select(товар => товар.Наименование);
foreach (var товар in запрос)
{
Console.WriteLine("{0} ", товар);
}
Генерируется следующий запрос
SELECT
[Extent1].[DESCR] AS [DESCR]
FROM [dbo].[SC84] AS [Extent1]
WHERE ([Extent1].[DESCR] LIKE @p__linq__0 ESCAPE N'~')
OR([Extent1].[DESCR] LIKE @p__linq__1 ESCAPE N'~')
OR([Extent1].[DESCR] LIKE @p__linq__2 ESCAPE N'~')
Поясню. Есть обобщенная функция с ограничением на СправочникПредок в котором есть свойство Номенклатура в которую подается список строк.
Запрос возвращает все элементы которые содержат в наименовании любую строку из списка
и солнце б утром не вставало, когда бы не было меня
Схему я показывал здесь
Да она расширяет возможности, и доступна в том числе и для C++, причём без зацикленности на T4.
