Паля

Нет ну причём тут ИТОГИ?
То что вы написали ВООБЩЕ ничего не означает. о чём эти наблюдения?

Сделайте два одинаковых запроса с группировкой.
Добавьте к одному из них расчёт итогов.
Запустите один и второй - посмотрели разницу увидели что разница большая - объяснили почему.
затем на разных количествах строк ещё надо убедится что зависимость от итогов существенная и несравнима с тормозом от обхода таблицы языком 1с и обращения к полям.
Мне лично очевидно, что нет проблем считать итоги на клиенте и во много раз быстрее чем обход таблицы скриптом 1с. если это не так, то просто надо это показать и удивится багу платформы.
Ваш пример не демонстрирует ничего.

Паля, ключевые слова здесь: Построитель отчета и отчет "Анализ доступности товаров на складах".

Расшифрую все по полочкам: Стандартный отчет "Анализ доступности товаров на складах" использует для запроса и его вывода объект ПостроительОтчета (котрый вызывается через Универсальный Отчет) и два его метода:
1. ПостроительОтчета.Выполнить() - выполняется запрос к SQL серверу.
2. ПостроительОтчета.Вывести() - выполненный запрос выводиться в табличный документ. (метод в коде универсального отчета идет следом за ПостроительОтчета.Выполнить(), т.е. никаких промежуточных расчетов не осущевстляется )

В тесте стоят умолчанию настройки для этого отчета, т.е. группировки Склад и Номенклатура, включена галка - выводить итоги.

По первому пункту - метод выполнить, выполняет запрос и по скорости был приблизительно равен, скорости выполнения запроса в MS SQL и естественно + время трансляции.
По второму пункту - метод вывести, как раз и выводит отчет в Табличный документ, который передается ему в качестве параметра, как раз таки когда бежит бегунок в отчете снизу это и есть время работы этого метода, т.е. никаких кривых ручек подобных предположенными вами вариантами развития событий:
Паля В тесте необходимо проверить что при вычислении итогов не осуществляется обращения к ссылочным объектам для получения представления.

Это тоже может тормозить, но собственно к вычислению итогов не относится.
здесь в принципе быть не может, т.е. обращения к выборке из языка 1С кроме ПостроительОтчета.Вывести(), отсутствуют как класс.

Так вот в соответсвии со всем этим можно сделать вывод, что суперагрегирование происходит средствами 1С происходит оно гораздо медленнее чем сам отчет, в тесте указанно, что вывод отчета занимает 98% времени.
Сейчас на память (т.к. действо происходило в 2007) могу сказать, что вывод отчета занимал несколько минут.
Пусть в отчете даже 10000 позиций наличиствующей номенклатуры, такой вывод занимает непозволительное количество времени. В других более простых отчетах, тот же отчет "Ведомость по товарам на складах" вывод отчета занимал несколько секунд. Поэтому и был сделан вывод о том, что существeт зависимость скорости агрегирования от количества таблиц используемых в запросе.

Кстати сам Group By относительно выборки в запросе используется, на что, мне и было указанно постом ниже. Т.е. можно сделать вывод, что потери времени происходят именно на суперагрегировании, т.е. на том , что в MS SQL фактически делает WITH ROLLUP, за исключением вот этого :
ДжиннЯ бы хотел посмотреть, как уважаемый критик средствами SQL сделал бы группировку с итогами по иерархии :)

этого WITH ROLLUP делать не умеет. Но данная проблема на T-SQL решается другими путями и т.к. в моем тесте группировки по групам не используются данное замечание к скорости выполнения моих тестов не имеет никакого отношения.


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

Да и еще все же более критично подходите к 1С, недостатков, не смотря на все ее достоинства, в ней хватает с избытком.

Паля
Во! Это уже похоже на разговор!


Паля если вы хотите проводить разговор, а не "сраца по существу" (с) то подобные вашему заявления, здесь неуместны:

Паляне надо пихать безграмотные ссылки на никому не нужные мнения дилетанта.
Паляэтож ерунда полная написана!

и т.п. в более завуалированной форме.

В отношении ваших постов, в подобном тоне еще никто из участников обсуждения не позволял себе высказываться.

Паля
(ээ. а без галочки итоги всё быстро работает? )


Проводить такие тесты без галочки, не корректно, т.к. WITH ROLLUP выдает информацию с общими итогами.

Паля
Начали кстати с языка запросов и ИТОГОВ. а вы из слишком высокоуровнего отчета делаете далекоидущие выводы.

Опять же не представляйте мои выводы как далеко идущие, они достаочно ограниченны:
ИТОГИ ПО работают не всегда с той производительность которую дает WITH ROLLUP.

Паля
Я настаиваю на GROUP BY потому что Totals и GROUP BY работают очень похоже и вообще это почти одно и тоже при выгрузке по группировкам.

Естественно работают с одинаковой скоростью, ведь Totals использует GROUP BY и мы сравниваем не скорость агрегирования, а скорость суперагрегирования т.е. WITH ROLLUP vs ИТОГИ ПО (Totals).

Паля
Пока из ваших слов ясно что в построителе запросов в некоторых случаях отчеты выводится медленно и это может быть связано с итогами. Ну может быть. Может проблема с выводом в макет секции итоги?


вы не правы. Очевидно что здесь это самое обращение для получения представления и происходит. в запросе вы получаете ссылку - в таблицу выводится наименование справочника. получение наименования по ссылке должно быть где-то и кем-то осуществлено. и функция вывести это делает и это значительное время.

Я бы с вами согласился если бы, в том же отчете "Ведомость по товарам на складах", были бы аналогичные проблемы, но таких проблем не наблюдалось. А оба отчета выводят одинаковое количество строк т.к. "Заказы поставщикам" на том предприятии не использовались.
Настройки по умолчанию в отчете "Ведомость по товарам на складах" такие же как и в "Анализ доступности" - Группировки Склад, Товар, галочка итоги стоит. Нулевая загрузка SQL сервера тоже показательна, да и в профайлере я такой ужас увидел бы сразу, открытый курсор либо >10 000 запросов по получению "Наименований" номенклатуры не возможно не заметить.
Хотя каюсь, мое изначально ошибочное предположение об отсутствии Groop By (видимо, ошибочно отнес последний Groop By к предстоящему Union ALL) в запросе не дало мне сфокусировать внимание на других вещах в частности на запросе по получению представлений :(, и так как такой запрос все же был (в приведенном мною запросе, получения Наименований нет), не выполнялся он несколько минут, иначе я бы его заметил :)

ПаляНе надо никаких построителей.
В топике идет указание именно на проблемы в построителе отчетов:
vitkhv
как я понял из своих наблюдений 1С тянет на сервер предприятия выборку и там ее группирует в соответсвии с параметрами указанными в построителе отчетов.

и нет никакой экстраполяции результатов на обычные запросы.
Хотя если хорошо подумать, можно с проецировать выводы и на обычные 1С запросы в которых используется ИТОГИ ПО.

Паля
Нужно сделать запрос с итогами и без. c group by и без. (order by и без)
и вызвать у запроса метод выгрузить (с группировкой и без. ).
Исключить получение представлений по ссылкам.

Посчитать время исполнения каждого из двух методов и подумать.
Только после этого можно хоть что-нибудь интересное утверждать.


Паля, может быть вы подготовите для нас такие тесты? А то ваших постах ровно такие же как и у нас "ничем не подкрепленные" утверждения по типу, "я настаиваю", ну раз настаиваете, все карты вам в руки ;).
В частности для меня было бы интересно увидеть, что в этом отношении изменилось с 2007 года.

Паляссылка действительно безграмотная (только для зарегестрированных и не разворачивается основной запрос) т.е. вы безграмотность ссылки определяете по тому, требуется ли там регистрация или не требуется? Паля, вы не исправимы.

ПаляОпять же не представляйте мои выводы как далеко идущие, они достаочно ограниченны:
ИТОГИ ПО работают не всегда с той производительность которую дает WITH ROLLUP.
Ну это слишком слабое утверждение. ясно дело что не всегда и вообще любая обработка данных в 1с - тормозит неимоверно (по сравнению с нормальными языками или sql сервером) .
ЛЮБАЯ. поэтому упоминать о том что тормозят итоги надо не на фоне ролапа а на фоне клиентской обработки..

Теоретически так, но в нашем случае тема, есть ли аналог WITH ROLLUP в 1С. Но по вашему 1С конечно же не причем, скорость работы ее конкретных методов можно только сравнивать с гипотетической клиентской обработкой, все остальные сравнения по вашему некорректны.


Паля
Vitkhvкак я понял из своих наблюдений 1С тянет на сервер предприятия выборку и там ее группирует в соответсвии с параметрами указанными в построителе отчетов.
Ну как вы уже поняли - это не так.


Не выдергивайте из контекста, я понял, что это не так еще в 2007 году и лично вы в этом никак не поучаствовали.

Паля
я не умею. я бездельник (в смысле теоретег).


Т.е. вы для себя даже теоритечески не можете допустить мысли, о том что Итоги ПО и были причиной торомзов, виновата конечно же была (конечно только теоретически) отрисовка этого отчета на экране. А все мои аргументы и утверждения конечно же слабы.

Палято что построитель отчета тормозит при выводе на экран - это понятно.
то что итоги в запросе занимают некоторое время для расчета - тоже понятно.
что значит что "итоги по" "тормозят" - непонятно.

Ну надо поизучать почему так. и в чём тут затык.
Не понимаю: какое утверждение о скорости работы итогов в 1с вы можете сформулировать на основе этих посылок? :-) (то что они не так быстро как роллап это очевидно и не так быстро как много других операций тоже).
(например : Есть два отчета. и там и там стоит галочка итоги. один из них выводит на экран данные 5минут второй 10 секунд => очевидно итоги в 1с работают медленно! доколе!)

Опять вы передергиваете. Я вам представляю одно утверждение как подкрепление второго, вы берете это подкрепляющее утверждение и делаете из него цирк, как будто первого утверждения и не существует. Т.е. как в анекдоте про Логику - раз спичек нет, значит Импотент.
Так же и мои аргументы у вас превращаются в это: Есть два отчета. и там и там стоит галочка итоги. один из них выводит на экран данные 5минут второй 10 секунд => очевидно итоги в 1с работают медленно!
С таким подходом общение с вами напрягает и какой либо аргументированный спор с вами становиться просто бессмысленным.