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

Подскажите\расскажите\покажите, как можно сравнить скорость выполнения запроса (штатного и прямого) до тысячных секунды желательно...

Спасибо заранее

Запустить тысячу раз и измерить до секунды :)

(0) Отладчиком воспользоваться.

_GetPerformanceCounter();
тебе поможет.

+2 Еще тупой вариант вставить кусок кода в начало и конец:
Сообщить("Начало "+ТекущееВремя());
Сообщить("Конец "+ТекущееВремя());

(4)Текущее время, на сколько я знаю до секунд... если у меня запрос выполняется доли секунды. нужно знать это время... Так же замерять и штатный запрос...

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

(6) В том то и дело... один и тот же запрос переписал на прямой... при выполнении даже невооруженным взглядом видно, что скорость выше на порядок... Ну хотелось бы знать точное время выполнения.

имхо измерять время в тысячных глупо - слишком велика погрешность
либо несколько запросов в цикле, либо запрос на большем объеме данных тестировать
про _getperfomancecounter уже написали

(3) Спасибо, то что доктор прописал ))

(8) Естественно для замеров будет делаться запрос в цикле и вычисляться среднее. Так же спасибо за функцию. На счет объема данных не думал, но мысль хорошая.. развернуться есть где :)

Всем спасибо

(9)и еще если делаешь запросы за период, не советую использовать при выполнении подряд один и тот же период.
Потому как SQL кеширует результат запроса.

(5) Ну и кому нужны твои тысячные? Потратить день и увеличить скорость на 0,001 ? Да за такое нада пальцы в двери, а еще лучше что б и не плодились.
Любые потуги которые в результате дают меньше 10% прироста - яйца выеденного нестоят.

(11) верное замечание.
Вот я промучался с переводом расчетов на прямые запросы в модулях проведения.
Да времени ушло немало.
НО!
время проведения сократилось в 10 раз!

потрясающий результат! я переписал только модуль проведения заявки покупателя, получились интересные результаты :) при проведении задним числом быстрее в 5-8 раз, собственно по ТА такой же результат :)

(7) на порядок это мало, или прямой запрос не очень оптимален, или у них планы почти одинаковые

попробуй использовать данный код:
в глобальном модуле

Процедура глТНачатьЗамер() Экспорт
    глТЗамер.ДобавитьЗначение(_GetPerformanceCounter());
КонецПроцедуры

Функция глТЗакончитьЗамер() Экспорт //++ ReLock (19.10.2005)
    КонВремя = _GetPerformanceCounter();
    КонДни = 0;
    КонЧасы = 0;
    КонМинуты = 0;
    КонСекунды = 0;
    КонМиллиСек = 0;
    КолЗамеров = глТЗамер.РазмерСписка();
    Если КолЗамеров = 0 Тогда
        // Раз нет стартовой даты - значит процедура начала отсчета времени не была запущена.
        Возврат "Замер времени не начат!";
    КонецЕсли;
    ОстатокВремени = КонВремя - глТЗамер.ПолучитьЗначение(КолЗамеров);
    КонДни = Цел(ОстатокВремени / 86400000); //++ 86400000 - Количество миллисекунд в сутках
    ОстатокВремени = ОстатокВремени - КонДни * 86400000;
    КонЧасы = Цел(ОстатокВремени / 3600000); //++ 3600000 - Количество миллисекунд в часе
    ОстатокВремени = ОстатокВремени - КонЧасы * 3600000;
    КонМинуты = Цел(ОстатокВремени / 60000); //++ 60000 - Количество миллисекунд в минуте
    ОстатокВремени = ОстатокВремени - КонМинуты * 60000;
    КонСекунды = Цел(ОстатокВремени / 1000); //++ 1000 - Количество миллисекунд в секунде
    ОстатокВремени = ОстатокВремени - КонСекунды * 1000;
    КонМиллисек = ОстатокВремени;
    ТекСтрока = Строка(КонДни) + "/" + Формат(КонЧасы,"Ч(0)2") + ":" + Формат(КонМинуты,"Ч(0)2")
    + ":" + Формат(КонСекунды,"Ч(0)2") + "."       + Формат(КонМиллиСек,"Ч(0)3");
    глТЗамер.УдалитьЗначение(КолЗамеров);
    Возврат ТекСтрока;
КонецФункции


и по мере выполнения кода

    ВремВыполнения = СоздатьОбъект("СписокЗначений");

    глТНачатьЗамер(); //0 - Замер общего времени
    ТекущаяДатаТА = ПолучитьДатуТА();
    
    глТНачатьЗамер();//1 замер
    УстановитьТАна(ДатаСвертки+1);
    ВремВыполнения.ДобавитьЗначение("Перенос ТА на нужную дату за: " + глТЗакончитьЗамер());    //закрытие 1 замера
    ВремВыполнения.ДобавитьЗначение("Общее время выполнения: " + глТЗакончитьЗамер());//закрытие общего замера
    
    Для а = 1 ПО ВремВыполнения.РазмерСписка() Цикл
        Врем = "";
        Сообщить(ВремВыполнения.ПолучитьЗначение(а, Врем));
    КонецЦикла;




и результат будет примерно такой
Документы провелись за: 0/00:18:28.201

я просто слышал что отладчик время считает от тактовой частоты процессора, и время выполнения общее в отладчике никогда не совпадало с реальным, у меня по крайней мере...
Перенос ТА на нужную дату за: 0/00:00:26.595
Значения периодических реквизитов удалены за: 0/00:01:23.948
Документы помечены на удаление: 0/00:00:00.000
Документы ввода начальных остатков введены за: 0/00:01:24.066
Перенос ТА на нужную дату за: 0/00:00:09.500
    Помечаем на удаление найденных контрагентов и подчиненные справочники: 0/00:00:13.712
    Поиск и пометка на удаление неактивнх товаров: 0/00:00:02.976
    Удаляем движения регистров: 0/00:00:00.536
    Делаем документы непроведенными: 0/00:01:44.364
Все движения регистров удалены. Вся лишняя информация помечена на удаление за: 0/00:02:01.589
Перенос ТА на нужную дату за: 0/00:00:01.383
Проведение документов ввода начальных остатков: 0/00:01:45.360
Общее время выполнения: 0/00:07:12.441

(11) Откуда столько ненависти то.... я хочу видеть прирост производительности в целом... Запрос за 1 день даст результат один, за год уже совсем другой... а если 20 пользователей сразу запустят каждый свою отчетность... так вот мне и нужно знать. стоит это того, чтобы переводить на прямые или нет.

А любые потуги.. Хм, не знаешь на каком проекте сижу и что делаю, не нужно делать выводы...

И видимо перед тем. как браться и делать, я хочу видеть, чтоб это стоило того.

А если брать в целом задачу, на данный момент это оптимизация базы в целом. Тут косяков и г*** столько, что не перечесть... Так вот вопрос к тебе, Бобрик.. если все равно буду менять процедуры и модули, так почему не переписать на прямой и затратить на него, путь даже 1 час.. А лучше всего, если в кучи документах одинаковые процедуры, не вынести в глобальник и кинуть на нормальный запрос?
И да. я не из тех людей. которые кинуть задачу и будут сидеть нихрена не делать.. как минимум практика в написании запросов и вообще оптимизации кода никому никогда не мешает.

не парься, думаю оно того стоит, выше пример свертки базы делал очень долго, стандартная работала неделю! на прямых запросах и измененным алгоритмом как видишь 7 минут (4-7 минут)

(18) Если реально хочешь "если в кучи документах одинаковые процедуры, не вынести в глобальник и кинуть на нормальный запрос", то посмотри заодно и в сторону классов 1С++, ими пользоваться (и допиливать на ходу) удобнее, чем глобальником.

(20) во во!

(18) При нормальной скульной железке особой разницы нету - запустит 1 пользователь или 20. Расхождение будет не больше 10%. Поэтому если есть мнение что ускорив запрос на 1% при одновременном запуске 20 пользователями получим ускорение в 10% - это ошибочное мнение.
Пользуйся отладчиком, там посмотри замер и оптимизируй начиная с максимального времени выполнения. Просто пытаться оптимизировать кусок кода который занимает 5% и пропускать код который занимает 30+ процентов - немного для меня непонятно. Ну это образно говоря.
Теперь что касается вопроса. Все прекрасно знают узкие места типовых. И да, часть из них сидит в глобальнике. Можно конечно пытаться оптимизировать, но максимальное ускорение будет только когда в проведение будет выдаваться уже готовое значение а не рассчитываться в модуле. Поэтому лучше пойти по этому пути, а не тратить время и всеравно придти к этому пониманию.
Ну и незабываем что конфигурация должна одинаково работать как в дбф так и в скульном вариантах. Поэтому переписывать все под скуль и забить на дбф - это наступать на грабли.

(22) На самом деле тема вопроса подразумевает образный подход к базе... Задачу, которую себе поставил - оптимизация в целом.. Если для типовых более менее понятно в каких местах копать, то в самописной это жестоко...
Идея как таковая собирать данные по работе пользователей. Во-первых будет информация чем же все-таки они пользуются и что в первую очередь надо просматривать... что из этого у них занимает больше времени... Часть запросов перепишу на прямые, т.к. уже по тестам видно, что криво написаны...
Более того покажется глупой эта работа, но буквально через год перейдем на 8-ку. В связи с этим ДБФ вариант не рассматриваю.. да и при таком документообороте dbf база через месяц достигнет максимума.

На счет готового значения в модуле полностью соглашусь... Очень не понятно, для чего в модуле проведения куча рассчетов с записью значений в справочники и созданием документов... ну и как следствие транзакции наш очень частый гость.

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