Re[40]: Тормознутость и кривость linq
От: Evgeny.Panasyuk Россия  
Дата: 25.03.16 02:22
Оценка:
Здравствуйте, ·, Вы писали:

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

_>>·>Реально в тривиальных случаях.
_>>В каких ещё тривиальных случаях? ) Раньше вообще только так весь код писали и всё. )))
dot>Так раньше код на перфокартах писали... и что?

А то что на перфокартах сейчас если и пишут, то только в развлекательных/познавательных/исторических целях.
А вот sql-строчки до сих пор используются в реальных проектах — на том самом C#, и на том самом stackoverflow:

https://github.com/StackExchange/dapper-dot-net
Dapper is in production use at:
Stack Overflow, helpdesk

Re[40]: Тормознутость и кривость linq
От: alex_public  
Дата: 25.03.16 09:25
Оценка:
Здравствуйте, ·, Вы писали:

_>>В каких ещё тривиальных случаях? ) Раньше вообще только так весь код писали и всё. )))

·>Так раньше код на перфокартах писали... и что?

Какие ещё перфокарты? ) До сих пор все веб-движки так и написаны. Загляни в любой и увидишь там эти самые sql строки. Правда в нормальных проектах они обычно отделены в специальный слой (DBAL), чтобы не быть привязанным к конкретной СУБД.

_>>В этой же темке обсуждался другой вопрос. Что в .net попытались создать некое подобное такой системы на базе задание запросов в виде linq выражений и разбора их потом в рантайме. Удобство и безопасность они при этом реализовать сумели, но только ценой большого оверхеда (т.е. кроме указанной выше склейки строк и параметров в рантайме делается ещё куча всего ненужного, типа обходов деревьев linq выражений через рефлексию и т.п.). Оценки этого оверхеда (те самые реальные замеры, которые ты хотел) можно увидеть в сообщения выше — там местами до 500% доходит. )))

·>Там замеры были или корявые (ну кто меряет тест выполнения запросов, выполняя инструкцию 1 раз и сравнивая 10мс и 13мс?! и делая вывод — 146%!). Либо тормоза возникали из-за других фич. Измерение конкретно рефлексии или склейки строк не было. Или я что-то пропустил?

Ну видимо пропустил (http://rsdn.ru/forum/flame.comp/6392078.1
Автор: alex_public
Дата: 22.03.16
), т.к. там и с измерениями всё нормально и тест идеально подходящий (можно увидеть реализацию и на sql строках и на linq для одной и той же ORM).
Re[41]: Тормознутость и кривость linq
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.03.16 09:59
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну видимо пропустил (http://rsdn.ru/forum/flame.comp/6392078.1
Автор: alex_public
Дата: 22.03.16
), т.к. там и с измерениями всё нормально и тест идеально подходящий (можно увидеть реализацию и на sql строках и на linq для одной и той же ORM).


Там с замерами лажа
Func<int> simpleEfDbContextCodeFirstTop10 = () =>
            {
                using (var ctx = new NorthwindEfDbContextCodeFirst())
                {
                    var list =
                        (
                            from o in ctx.Orders
                            join c in ctx.Customers on o.CustomerID equals c.CustomerID
                            select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
                        ).Take(10).ToList();
                    return list.Count;
                }
            };


Если хотим в равные условия то тогда и AsNoTrackig добавить.
http://www.c-sharpcorner.com/UploadFile/ff2f08/entity-framework-and-asnotracking/

http://metanit.com/sharp/entityframework/4.8.php

Кроме того такие запросы предварительно можно компилировать.
А можно и использовать тот SqlConnection для пакетных запросов или использовать специфические для каждой бд инструкции.
Мало того от версии к версии все меняется.
То есть есть огромная свобода. Но ты привязан только к скорости.
Еще раз основная доля учетных систем написана на 1С. Важна скорость и надежность разработки. Но тебе этого не понять. Ведь на С++ пишутся простые и понятные программы только для тебя.
и солнце б утром не вставало, когда бы не было меня
Re[27]: Тормознутость и кривость linq
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.03.16 11:30
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Вообще то в данном контекте речь шла о сравнение вариант на C# с linq vs вариант на C# с голыми sql строками. И в данном случае все тормоза от работы с linq тут являются чистым оверхедом.

НС>>А теперь посмотрим на практику — http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html

_>Вот, отлично! Наконец то не просто отзывы профессионалов на форуме, а уже специальные замеры. И они полностью подтверждают мои слова. Даже более того, я конечно ожидал десятков процентов тормозов, но не 50% для лучшей реализации и 500% для худшей (однако более популярной). Естественно такие радикальные цифры наблюдаются только для быстрых запросов. В случае же тяжёлых запросов величина оверхеда относительно времени исполнения самого запроса естественно снижается, до соответственно 10% в лучшей реализации и 100% в худшей. Что всё равно очень много на мой взгляд.


_>P.S. Цифры для EF конечно же вообще шокирующие. )))

_>P.P.S. Теперь будет куда тыкать носом всяких умников, которые тут болтают про бред или просто молча минусы рисуют... )))

Вот давай как раз ум то и включим
Берем CodeFirst
Func<int> simpleEfDbContextCodeFirstTop500 = () =>
            {
                using (var ctx = new NorthwindEfDbContextCodeFirst())
                {
                    var list =
                        (
                            from o in ctx.Orders
                            join c in ctx.Customers on o.CustomerID equals c.CustomerID
                            select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
                            ).Take(500).ToList();
                    return list.Count;
                }
            };


И ADO
Func<int> simpleAdoNetTop500 = () =>
            {
                int count = 0;
                using (var con = new SqlConnection(connectionStringNorthwind))
                {
                    con.Open();
                    var sql = @"
SELECT TOP 500 O.OrderID, O.OrderDate, C.Country, C.CompanyName
FROM Orders O
JOIN Customers C ON O.CustomerID = C.CustomerID
                            ";
                    using (var cmd = new SqlCommand(sql, con))
                    {
                        using (var reader = cmd.ExecuteReader())
                        {
                            if (reader.HasRows)
                            {
                                var list = new List<SimpleQueryRow>();
                                while (reader.Read())
                                {
                                    list.Add(new SimpleQueryRow
                                    {
                                        OrderId = reader.GetInt32(0),
                                        OrderDate = reader.IsDBNull(1) ? null : (DateTime?)reader.GetDateTime(1),
                                        Country = reader.IsDBNull(2) ? null : reader.GetString(2),
                                        CompanyName = reader.IsDBNull(3) ? null : reader.GetString(3),
                                    });
                                }
                                count = list.Count;
                            }
                        }
                    }
                }
                return count;
            };


Первое это нет AsNoTracking. То есть .Net отображает данные на объект и начинает искать в кэше объекты и обновлять их.
Второе в CodeFirst там не простая надстройкa
http://infostart.ru/public/393228/
http://infostart.ru/public/402433/

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

Используя предка, можно написать обобщенную функцию.



public TEntity ПолучитьЭлементСправочника<TEntity>(string ID) where TEntity : СправочникПредок

{





var query2 = from спр in this.Set<TEntity>()

where спр.ID == ID

select спр;

return query2.SingleOrDefault<TEntity>();



}



Теперь мы можем вызвать её таким способом

 

public static СправочникПредок ПолучитьЗначениеНеопределенногоСправочника(string НеопределенныйИД)

        {

            var тип = НеопределенныйИД.Substring(0, 4);

            var id = НеопределенныйИД.Substring(4, 9);

 

            switch (тип)

            {

                case ВыдСправочника36.Аналоги:

                    return БД.ПолучитьЭлементСправочника<Справочник.Аналоги>(id);

                case ВыдСправочника36.Банки:

                    return БД.ПолучитьЭлементСправочника<Справочник.Банки>(id);





При получении неопределенного справочника нам доступны все свойства и методы предка.

Следует отметить, что Linq возвращает не реальный объект, а прокси. То есть для того, что бы получить реальный тип нужно вызвать GetType().BaseType

А эта надстройка может реализовать изменения, биндинг итд, на что тоже тратится время.

https://msdn.microsoft.com/en-us/data/jj592872.aspx

Кроме того есть более интересные запросы

Есть еще одна замечательная особенность — это использование переменных в запросе



Суть запроса такова. Сгруппируем единицы по владельцу, количество подчиненных которых превышает один элемент. Запрос будет выводить дерево по Владельцу, при этом в корне мы получаем агрегированные данные (Count())


var бд = Константы1С.ГлобальныйКонтекст.БД;

       

            var qr = (from единица in бд.Спр_Единицы

                      group единица by new {

                          единица.ВладелецId,

                          Наименование=единица.Владелец.Наименование.TrimEnd()

                          }

                          into группа

 

                          let Количество = группа.Count()

                          where Количество > 1

 

                      selectnew

                      {

 

                          Наименование = группа.Key.Наименование,

                          Количество = Количество,

                          Группа = группа

                      });

 

 

            foreach (var элем in qr)

            {

              //     Console.WriteLine("{0}.{1} - ", элем.Наименование,  элем.Количество);

               

                foreach (var единица in элем.Группа)

                {

 

                    Console.WriteLine("{0}.{1} - ", единица.ОКЕИ.Наименование, единица.ШтрихКод);

                

                }

            }

 

 

Генерирует такой запрос

 

SELECT

    [Project1].[C2] AS [C1], 

    [Project1].[C3] AS [C2], 

    [Project1].[C1] AS [C3], 

    [Project1].[PARENTEXT] AS [PARENTEXT], 

    [Project1].[C4] AS [C4], 

    [Project1].[ID] AS [ID], 

    [Project1].[PARENTEXT1] AS [PARENTEXT1], 

    [Project1].[ISMARK] AS [ISMARK], 

    [Project1].[SP79] AS [SP79], 

    [Project1].[SP76] AS [SP76], 

    [Project1].[SP78] AS [SP78], 

    [Project1].[SP80] AS [SP80], 

    [Project1].[SP8752] AS [SP8752], 

    [Project1].[SP9519] AS [SP9519]

    FROM ( SELECT 

        [GroupBy1].[A1] AS [C1], 

        [GroupBy1].[K1] AS [PARENTEXT], 

        [GroupBy1].[K2] AS [C2], 

        [GroupBy1].[K3] AS [C3], 

        [Join2].[ID1] AS [ID], 

        [Join2].[PARENTEXT] AS [PARENTEXT1], 

        [Join2].[ISMARK1] AS [ISMARK], 

        [Join2].[SP79] AS [SP79], 

        [Join2].[SP76] AS [SP76], 

        [Join2].[SP78] AS [SP78], 

        [Join2].[SP80] AS [SP80], 

        [Join2].[SP8752] AS [SP8752], 

        [Join2].[SP9519] AS [SP9519], 

        CASE WHEN ([Join2].[ID1] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C4]

        FROM   (SELECT 

            [Join1].[K1] AS [K1], 

            [Join1].[K2] AS [K2], 

            [Join1].[K3] AS [K3], 

            COUNT([Join1].[A1]) AS [A1]

            FROM ( SELECT 

                [Extent1].[PARENTEXT] AS [K1], 

                1 AS [K2], 

                RTRIM([Extent2].[DESCR]) AS [K3], 

                1 AS [A1]

                FROM  [dbo].[SC75] AS [Extent1]

                INNER JOIN [dbo].[SC84] AS [Extent2] ON [Extent1].[PARENTEXT] = [Extent2].[ID]

            )  AS [Join1]

            GROUP BY [K1], [K2], [K3] ) AS [GroupBy1]

        LEFT OUTER JOIN  (SELECT [Extent3].[ID] AS [ID1], [Extent3].[PARENTEXT] AS [PARENTEXT], [Extent3].[ISMARK] AS [ISMARK1], [Extent3].[SP79] AS [SP79], [Extent3].[SP76] AS [SP76], [Extent3].[SP78] AS [SP78], [Extent3].[SP80] AS [SP80], [Extent3].[SP8752] AS [SP8752], [Extent3].[SP9519] AS [SP9519], [Extent4].[DESCR] AS [DESCR]

            FROM  [dbo].[SC75] AS [Extent3]

            INNER JOIN [dbo].[SC84] AS [Extent4] ON [Extent3].[PARENTEXT] = [Extent4].[ID] ) AS [Join2] ON ([GroupBy1].[K1] = [Join2].[PARENTEXT]) AND(([GroupBy1].[K3] =(RTRIM([Join2].[DESCR]))) OR(([GroupBy1].[K3] IS NULL) AND(RTRIM([Join2].[DESCR]) IS NULL)))

        WHERE [GroupBy1].[A1] > 1

    )  AS [Project1]

    ORDER BY [Project1].[C2] ASC, [Project1].[PARENTEXT] ASC, [Project1].[C3] ASC, [Project1].[C4] ASC






Это уже не просто склейка строк.
и солнце б утром не вставало, когда бы не было меня
Re[42]: Тормознутость и кривость linq
От: alex_public  
Дата: 25.03.16 11:49
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ну видимо пропустил (http://rsdn.ru/forum/flame.comp/6392078.1
Автор: alex_public
Дата: 22.03.16
), т.к. там и с измерениями всё нормально и тест идеально подходящий (можно увидеть реализацию и на sql строках и на linq для одной и той же ORM).


S> Там с замерами лажа

S> Если хотим в равные условия то тогда и AsNoTrackig добавить.
S>http://www.c-sharpcorner.com/UploadFile/ff2f08/entity-framework-and-asnotracking/
S>http://metanit.com/sharp/entityframework/4.8.php

Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.

S>Кроме того такие запросы предварительно можно компилировать.

S>А можно и использовать тот SqlConnection для пакетных запросов или использовать специфические для каждой бд инструкции.
S>Мало того от версии к версии все меняется.
S>То есть есть огромная свобода. Но ты привязан только к скорости.

Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня.
Re[43]: Тормознутость и кривость linq
От: Danchik Украина  
Дата: 25.03.16 12:16
Оценка: +1 -1
Здравствуйте, alex_public, Вы писали:

[Skip]

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


Именно, спорить с тобой бесполезно. Приципился с этой рефлексией, а бенефита так и не увидел, потому что уже упрежденно что-то для себя похоронил.
Удачи тебе в склейке строк.
Re[43]: Тормознутость и кривость linq
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.03.16 12:48
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ну видимо пропустил (http://rsdn.ru/forum/flame.comp/6392078.1
Автор: alex_public
Дата: 22.03.16
), т.к. там и с измерениями всё нормально и тест идеально подходящий (можно увидеть реализацию и на sql строках и на linq для одной и той же ORM).


S>> Там с замерами лажа

S>> Если хотим в равные условия то тогда и AsNoTrackig добавить.
S>>http://www.c-sharpcorner.com/UploadFile/ff2f08/entity-framework-and-asnotracking/
S>>http://metanit.com/sharp/entityframework/4.8.php

_>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.

Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.
S>>Кроме того такие запросы предварительно можно компилировать.
S>>А можно и использовать тот SqlConnection для пакетных запросов или использовать специфические для каждой бд инструкции.
S>>Мало того от версии к версии все меняется.
S>>То есть есть огромная свобода. Но ты привязан только к скорости.

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

Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.
Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь.
Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.
и солнце б утром не вставало, когда бы не было меня
Re[44]: Тормознутость и кривость linq
От: alex_public  
Дата: 25.03.16 13:13
Оценка: +1 -1
Здравствуйте, Danchik, Вы писали:

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

D>Именно, спорить с тобой бесполезно. Приципился с этой рефлексией, а бенефита так и не увидел, потому что уже упрежденно что-то для себя похоронил.
D>Удачи тебе в склейке строк.

Зачем мне склейка строк? ) Я напишу вот так:
for(const auto& row: db(select(users.id, users.name).from(users).where(users.total>total))){
    int64_t id = row.id;
    //...
}
Re[44]: Тормознутость и кривость linq
От: alex_public  
Дата: 25.03.16 13:34
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.

S> Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.

Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).

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

S> Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.

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

S>Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь.

S> Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.

А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.
Re[45]: Тормознутость и кривость linq
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.03.16 14:20
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.

S>> Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.

_>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).

Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/

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

S>> Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.

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

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

S>>Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь.

S>> Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.

_>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.

1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая.
То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.
Опять же если хочешь сравнивать, то нужно их сравнивать правильно, в том числе и на сложных запросах с группированием данных в иерархии.
Опять же отображения на объекты нужны для редактирования. Обычные запросы как правило возвращают ID,Наименование и прочие поля. Да там тоже идет отображение на аноноимные типы, но не нужно отслеживать кэши и изменения.

На самом деле прошу прощения. До конца не просмотрел запрос

select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
).Take(500).ToList();
Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile

https://msdn.microsoft.com/ru-ru/library/bb399335(v=vs.110).aspx

И посмотреть где идет задержка.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 25.03.2016 14:28 Serginio1 . Предыдущая версия .
Re[46]: Тормознутость и кривость linq
От: alex_public  
Дата: 25.03.16 16:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).

S> Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/

Эээ что? ) Какой парсинг, какого текста? )

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

S> На самом деле нужно в основном динамические запросы строить особенно интерактивные.

Да что ты говоришь. ))) Ну вот например мы сейчас находимся на форуме. Он работает на основе sql БД (более того, он даже на linq2sql написан, но это к делу уже не относится). И в каких же местах по твоему тут нужны динамические запросы? )

_>>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.

S> 1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая.
S>То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.

Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина.

S>На самом деле прошу прощения. До конца не просмотрел запрос

S>select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
S> ).Take(500).ToList();
S>Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile
S>https://msdn.microsoft.com/ru-ru/library/bb399335(v=vs.110).aspx
S>И посмотреть где идет задержка.

Нуу вперёд, всем будет любопытно посмотреть на ещё варианты замеров) Только не забудь брать за базу вариант на ADO.NET. )))
Re[47]: Тормознутость и кривость linq
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.03.16 20:15
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).

S>> Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/

_>Эээ что? ) Какой парсинг, какого текста? )

Если ты читал мои статьи, то там названия полей могут быть отличными от полей в Базе. Кроме того там могут применяться объектные запросы.

Кроме того в Linq to EF можно использовать Entity SQL

Например





var str = @"Select VALUE  p From [Спр_Номенклатура] as p";

           var Запрос = qr.CreateQuery<Справочник.Номенклатура>(str );

           var res = Запрос.Execute(MergeOption.NoTracking);

 

           foreach (var элем in res)

            {

                Console.WriteLine("{0}.{1} - {2}", элем.Наименование.TrimEnd(), элем.Артикул, элем.ПолнНаименование.TrimEnd());

            }

Но по большому счету выхлоп от него небольшой



https://msdn.microsoft.com/ru-ru/library/bb738573(v=vs.110).aspx
Отличия Entity SQL и Transact-SQL


Идентификаторы
В языке Transact-SQL сравнение идентификаторов всегда осуществляется с учетом параметров сортировки текущей базы данных. В Entity SQL идентификаторы всегда чувствительны к регистру и диакритическим знакам (то есть Entity SQL различает диакритические знаки, например, «а» отличается от «?»). Entity SQL обрабатывает версии букв, которые кажутся такими же, но являются другими символами и происходят из других кодовых страниц. Для получения дополнительной информации см. Набор символов ввода (Entity SQL).
Функциональность Transact-SQL, недоступная в Entity SQL
Следующая функциональность Transact-SQL недоступна в языке Entity SQL.
DML
В настоящее время язык Entity SQL не поддерживает инструкции DML (вставка, обновление, удаление).
DDL
Текущая версия Entity SQL не поддерживает DDL.
Командное программирование
Язык Entity SQL не поддерживает командное программирование в отличие от Transact-SQL. Используйте вместо этого языки программирования.
Функции группирования
Язык Entity SQL пока не поддерживает функции группирования (например, CUBE, ROLLUP и GROUPING_SET).
Функции аналитики
Язык Entity SQL не предоставляет (пока) поддержку функций аналитики.
Встроенные функции, операторы
Язык Entity SQL поддерживает подмножество встроенных функций и операторов Transact-SQL. Вероятно, эти операторы и функции будут реализованы ведущими поставщиками хранилищ. В языке Entity SQL используются специальные функции для хранилищ, объявленные в манифесте поставщика. Кроме того, модель Entity Framework позволяет объявлять встроенные и пользовательские функции хранилища для использования в Entity SQL.
Подсказки
Язык Entity SQL не предоставляет механизм подсказок в запросах.
Пакетирование результатов запроса
Entity SQL не поддерживает пакетирование результатов запросов. Например, допустим следующий запрос Transact-SQL (отправляемый как пакет):


select * from products;

select * from catagories;

Однако эквивалент Entity SQL не поддерживается.
Select value p from Products as p;
Select value c from Categories as c;
Entity SQL поддерживает только запросы, которые выдают один результат на одну команду.



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

S>> На самом деле нужно в основном динамические запросы строить особенно интерактивные.

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

Угу. На этом форуме не так много запросов. С таким объемом и 1С прекрасно справляется. Система оооочень прочтая.

_>>>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.

S>> 1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая.
S>>То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.

_>Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина.


Со средненьким и 1С прекрасно справляется.

S>>На самом деле прошу прощения. До конца не просмотрел запрос

S>>select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
S>> ).Take(500).ToList();
S>>Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile
S>>https://msdn.microsoft.com/ru-ru/library/bb399335(v=vs.110).aspx
S>>И посмотреть где идет задержка.

_>Нуу вперёд, всем будет любопытно посмотреть на ещё варианты замеров) Только не забудь брать за базу вариант на ADO.NET. )))


Да на самом деле мне интересно, как меняется скорость от версии к версии. А вот насчет скорости, то берем и считаем стоимость и скорость разработки, стоимость поддержки. Считаем стоимость железа для поддержки необходимой производительности.
Могут быть трех звенки, двух звенки и гибриды того и другого. Вот кому платит за это и должно быть интересно.
Например на 1С там трех звенка и её можно разнести по кластерам. Но зато там мегабайты кода, но интерпретатор.
и солнце б утром не вставало, когда бы не было меня
Re[48]: Тормознутость и кривость linq
От: alex_public  
Дата: 27.03.16 08:45
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Эээ что? ) Какой парсинг, какого текста? )

S> Если ты читал мои статьи, то там названия полей могут быть отличными от полей в Базе. Кроме того там могут применяться объектные запросы.
S>Кроме того в Linq to EF можно использовать Entity SQL
S>Например
S>...

И какое это всё имеет отношение к обсуждаемой теме? )

S>>> На самом деле нужно в основном динамические запросы строить особенно интерактивные.

_>>Да что ты говоришь. ))) Ну вот например мы сейчас находимся на форуме. Он работает на основе sql БД (более того, он даже на linq2sql написан, но это к делу уже не относится). И в каких же местах по твоему тут нужны динамические запросы? )
S> Угу. На этом форуме не так много запросов. С таким объемом и 1С прекрасно справляется. Система оооочень прочтая.

Какое имеет отношение количество видов запросов к возможностям системы выдержать нагрузку? ) Даже если у тебя будет ровно один простой статический запрос (но не кэшируемый), то при миллионе запросов в секунду его не так просто выдержать будет. )))

_>>Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина.

S>Со средненьким и 1С прекрасно справляется.

Да? ) Т.е. 1C умеет работать например на десятке инстансов амазона или чем-то подобном? )

_>>Нуу вперёд, всем будет любопытно посмотреть на ещё варианты замеров) Только не забудь брать за базу вариант на ADO.NET. )))

S> Да на самом деле мне интересно, как меняется скорость от версии к версии. А вот насчет скорости, то берем и считаем стоимость и скорость разработки, стоимость поддержки. Считаем стоимость железа для поддержки необходимой производительности.

Ну так чтобы сделать все эти оценки надо же в начале всё же скорость работы оценить. Точнее если говорить в контексте нашей беседы, то оценить процент накладных расходов от Linq относительно времени основных запросов.
Re[45]: Тормознутость и кривость linq
От: Слава  
Дата: 27.03.16 12:09
Оценка: +1 :)
Здравствуйте, alex_public, Вы писали:

_>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.


Дались вам эти "высоконагруженные" сервисы. В большинстве случаев, это просто прожирание денег инвестора или продажа "перспективного проекта" от одного инвестора другому. Денег они сами не зарабатывают, в отличие от "формоклепских" приложений.
Re[49]: Тормознутость и кривость linq
От: Слава  
Дата: 27.03.16 12:13
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина.

S>>Со средненьким и 1С прекрасно справляется.

_>Да? ) Т.е. 1C умеет работать например на десятке инстансов амазона или чем-то подобном? )


Общеизвестно, что при интенсивном использовании железа, выгоднее его покупка, а не аренда у Амазона и тому подобных. Тем более, что никто свою коммерцию в облако отдавать не будет. Облака — это для фоток с котиками или для мапредьюса по фоткам инстаграмма.
Re[33]: Тормознутость и кривость linq
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.03.16 15:02
Оценка:
Здравствуйте, alex_public, Вы писали:

>Я правильно понял, что ты допускаешь ситуации, в которых linq решение обойдёт по скорости запрос на голых sql строках? ))) И даже не просто допускаешь, а говоришь что "есть масса реальных сценариев"? )


Разумеется. Что делать с твоими голыми sql строками если надо вдруг часть запроса выполнять, скажем, не против sql server а против out process кеша ?
Re[34]: Тормознутость и кривость linq
От: alex_public  
Дата: 29.03.16 22:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

>>Я правильно понял, что ты допускаешь ситуации, в которых linq решение обойдёт по скорости запрос на голых sql строках? ))) И даже не просто допускаешь, а говоришь что "есть масса реальных сценариев"? )

I>Разумеется. Что делать с твоими голыми sql строками если надо вдруг часть запроса выполнять, скажем, не против sql server а против out process кеша ?

SQL запрос к memcached? ) Это оригинально... Прекращай уже принимать там всякие препараты... )))
Re[45]: Тормознутость и кривость linq
От: Danchik Украина  
Дата: 30.03.16 10:57
Оценка: :)
Здравствуйте, alex_public, Вы писали:

[Skip]

_>Зачем мне склейка строк? ) Я напишу вот так:

_>
_>for(const auto& row: db(select(users.id, users.name).from(users).where(users.total>total))){
_>    int64_t id = row.id;
_>    //...
_>}
_>


Ты дальше упорото не понимаешь что тебе твердят. То что ты пишешь лишь частный случай и жостко захардкодженый.
Ты можешь вот это вот, "код"
db(select(users.id, users.name).from(users).where(users.total>total))

вынести в функцию и заджоинится на нее и получить нормальный SQL?
Re[46]: Тормознутость и кривость linq
От: alex_public  
Дата: 30.03.16 12:57
Оценка: +1
Здравствуйте, Danchik, Вы писали:

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

D>Ты можешь вот это вот, "код"
D>
D>db(select(users.id, users.name).from(users).where(users.total>total))
D>

D>вынести в функцию и заджоинится на нее и получить нормальный SQL?

Ты говоришь о чём-то вроде такого
auto F() {return select(users.id, users.name).from(users).where(users.total>total).as(rich_users);}

auto q=F();
for(const auto& row: db(select(orders.user).from(orders.join(q).on(orders.user==q.id)).where(orders.year>year))){
    //...
}

кода? Не пойму как в таких тривиальных вещах можно видеть что-то сложное и думать что реализация подобной элементарщины — это какой-то высокий уровень. )))
Re[35]: Тормознутость и кривость linq
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.03.16 13:46
Оценка:
Здравствуйте, alex_public, Вы писали:

>>>Я правильно понял, что ты допускаешь ситуации, в которых linq решение обойдёт по скорости запрос на голых sql строках? ))) И даже не просто допускаешь, а говоришь что "есть масса реальных сценариев"? )

I>>Разумеется. Что делать с твоими голыми sql строками если надо вдруг часть запроса выполнять, скажем, не против sql server а против out process кеша ?

_>SQL запрос к memcached? ) Это оригинально... Прекращай уже принимать там всякие препараты... )))


Ты же предлагаешь писать sql код вместо linq.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.