Здравствуйте!

Что-то я запутался совсем. Прошу помощи. Решил оптимизировать самописную конфигурацию, т.к. она работает через тонкий клиент и наблюдаются тормоза при работе разных алгоритмов. Возникли вопросы:

1. Стоит ли избавляться от всех обращений в коде алгоритмов вида Специалист = Объект.Специалист, если такое обращение находится в модуле формы?

В интернете много противоречивой информации на эту тему. Кто-то пишет, что надо получать такие данные запросом, кто-то говорит, что и так нормально. Я запутался в общем.

2. Стоит ли избавляться от получения реквизитов объекта через точку в запросе. Опять же кто-то пишет, что и так сойдет (платформа сама оптимизирует запрос для SQL), а кто-то пишет, что надо явно выполнять в запросах соединения с нужными таблицами.

Кто сталкивался? Надо менять? Или стоит сфокусироваться на другом?
Спасибо.

2.Очень просто проверяется с помощью профайлера.И кстати,А кто  там говорит,что можно?Особенно в свете гарцевания сертифакатов  хотелось бы узнать

1) Нет.
2) Нет.

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

Асириус, спасибо за ответ. Ну конечно я не имел ввиду, что надо избавляться тупо. Естественно, я бы подвергал такие изменения анализу. Возможно я не понимаю принципиальный момент, который хочу понять.

Говорят, что обращения через точку считывают в память целиком объект. Я не очень понимаю о каком объекте идет речь.

Если об объекте "Специалист" (Справочник), то он мне и нужен целиком, значит все ОК.

Если об объекте "Объект", то он итак находится в оперативной памяти, т.к. мы работаем в контексте этого объекта (модуль формы).

Так зачем тогда считывать данные из базы запросом? (как некоторые рекомендуют) Не понимаю... Хочу разобраться.

1. Вообще не понял зачем избавляться и от чего?
2. Стоит просто обратить на это внимание в каких-то самописных головоломных запросах и по возможности избавляться.

(4) Вы не там проблемы ищите.

(6) Спасибо, но я хочу разобраться. Когда разберусь с этим пойду дальше. Мой уточненный вопрос сформулирован в (4). Правильны ли мои умозаключения там? Если правильны, то тогда мне понятно почему не надо разбираться в этом и стоит пойти искать проблемы дальше.

(7) Нет, не правильны.

"Если об объекте "Специалист" (Справочник), то он мне и нужен целиком, значит все ОК. "

Вы не получите объект "Специалист" целиком. На стороне Тонкого клиента вы получите лишь ссылку на него и представление (в момент создания формы, либо после изменения реквизита)

(7) Замер производительности не предлагать?
сразу и найдешь, что оптимизировать надо

Через "точку", в контексте управляемого приложения речь может идти только о коде, выполняемом на сервере.
Вот там, из ссылки, через точку можно получить реквизит(ы), но делать так не надо.
Надо воспользоваться типовой процедурой ОбщегоНазначения.ЗначениеРеквизитаОбъекта(), а, лучше, посмотреть, где в типовом коде она применяется, и, зачем.

(10) Я уже замерил. Спасибо:) Через точку быстрее чем запросом) Вот и вообще крыша едет от прочитанных дискуссий в интернете, дескать, используйте запросы вместо обращения через точки.

Если это документ в тыщу строк, то запросом быстрее

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

(14) не будет разницы получить 1 реквизит или весь объект???

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

При этом вы пишите, что мои умозаключения в (4) не правильны. Поправка к (4): у меня контекст &НаСервере.

Так какие умозаключения мне сделать:

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

2. И чем это объясняется?

(15) Нет разницы 1 строка или тысяча, объект всё равно считан целиком. Разница на чтении одного объекта запросом и не запросом всё равно не будет очень большой, для простых объектов может быть и в другую сторону.
А вот для чтение 1000 объектов однозначно только запросом.

Через точку никогда не будет быстрее, чем запросом.

(18) даже если через точку вызовется кэшированное значение?

(11) Все верно говорите, применительно вот к этому:  где в типовом коде она применяется, и, зачем.

Был у меня один пример когда лучше работать через точку с реквизитами объекта, а не юзать ОбщегоНазначения.ПолучитьРеквизит(). А именно рекурсивная функция, которая могла в ходе работы еще раз обратиться к объекту для чтения, а могла и не обратиться. И когда я ког переписал на описанный выше пример, он стал тормозить примерно в 2,5 раза. А я знал, что так будет, решил заценить потери: а все было очевидно, на сервере есть сеансовый кэш и в данном случае его работа оказывает бОльший эффект.

(17) запросом он не будет считан целиком, будет считано только то, что указано в запросе.

(16)
Запросами нужно пользоваться тогда, когда необходимые данные лежат в базе. В вашем контексте, т.к. это "модуль формы", то в базе данных может не лежать. Или лежать другой версии. Т.е. обращение через точку оправдано. Но, если скажем, надо получить реквизит специалиста и редактирование его не входит в круг задач формы, то лучше получать запросом.
//Так можно:
Специалист = Объект.Специалист;
//Так нельзя:
График = Объект.Специалист.ГрафикРаботы;

Объяснение простое - правильно написанный запрос работает сильно быстрее обращения через точку.

Запрос не читает объект целиком как минимум из-за того что объект состоит из НЕСКОЛЬКИХ таблиц

(22) т.е. если нам нужно работать с объектом ссылочного типа (например СправочникСсылка.Специалисты), то нам пофигу как его получать: через точку или запросом, т.к. один хрен - он будет считан целиком.

А если нам нужно работать с реквизитами какого-то объекта, которые не являются ссылочными (и только с ними!), например с реквизитом (Специалист.ДатаРождения), то его лучше считать запросом, т.к. обращение Объект.Специалист.ДатаРождения считает объект "Специалист" целиком и это не оправдано для нас.

Я правильно все понял?

Но то что ты не там ищещь - это однозназно.
Любые работы по оптимизации начинаются с поиска узкких мест.
и не на глаз, а по замерам

Скорее всего твое получение через точку - это 0.001% от всего времени

(24) нет

(25) Это вы, фанаты Апдекса, этим страдаете.
Работы по оптимизации начинаются с написания оптимального кода изначально. Им, как правило, и заканчиваются.

(28) Чужой код сразу в помойку выкидываешь? не читая?

(20) Для рекурсивной функции лучше параметром тащить Соответствие со своим кэшом. Ну, если целостность данных не критична.

Замер это не только апдекс и скорее всего не апдекс, а тот же замер в отладчике

Хотя я подозреваю, что еж пишет идеальный код и ему даже и отладчик не нужен

(29) Чужой код у нас двух видов - типовой и другого нашего програмиста. Типовой код - исправляем в критичных местах, тут действительно Апдекс. Нашему программисту делаем внушение.

(31) Философия "Апдекс" - это оптимизация "от потребности". Моя философия - оптимизация изначально, и, оптимизация - "увидел, оптимизировал". Ибо, если не вылазит сейчас, то - вылезет потом.
НУ, как пример:
Жесть УТ11.2, как она есть.

(16) Попробую сформулировать.

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

Если же выполняется пакетная обработка набора объектов, и мы заранее не знаем, насколько большим будет этот набор, то нужно получать данные запросами. Например, при формировании отчетов. На больших объемах данных кэш объектов будет работать неэффективно. Большое количество объектов, использующихся разово, будет вытеснять из кэша другие полезные данные, использующиеся повторно.

(34) Сам себе противоречишь

(35) Кэш объектов в 1С НЕ работает (работал) эффективно, во времена моей юности. Возможно, сейчас поменялось что-то.
v8: Кэши разные нужны, кэши нужные важны..

(34) Все хорошие программисты переболели в свое время преждевременной оптимизацией. :) Это нормально. Пока.

(38) Болеем с 2006 года.

(38) А вы можете продолжать забивать болт.

(36) В каком месте?

(24) не правильно. Запрос выбирает только то, что попросишь. Тогда как обращение через точку поднимает весь объект.
Если ты в запросе напишешь ВЫБРАТЬ * ИЗ Тбл
То будет примерно тоже самое, что обращение через точку. Особенно заметно когда объект тяжелый - много реквизитов. И ещё сильнее заметно когда это безобразие работает в цикле.

Тип данных "реквизитов" роли не играет пока не попытаешься пойти дальше. Получить "Дату рождения"(Дата) или "Должность" (справочник ссылка должность) по нагрузке одинаково. Другое дело, что дата это простой тип, а у должности можно попробовать ещё свой реквизит получить, например Должность.КодПоКлассификатору. И тогда это будет ещё один не явный запрос. Правильнее запросами получать все необходимые данные. Вплоть до того, что если должность нужна только для вывода в печатную форму, то получать не должность как ссылку, а представление должности или наименование.

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

Я понимаю, что наступаю на больную мозоль, которые вам прикрываю фиговым листочком учителя, которые в свое время сделали также, но... Надо. А то вдруг вы еще вот туда попадете
https://moikrug.ru/vacancies/1000034462

А нервных клеток осталось мало.

(43) Это ты к чему?

(44) Это я к "мнимой" ненужности преждевременной оптимизации.

Оптимизация <> написанию хорошего кода

(46) Хороший код всегда оптимален.

Если код неоптимален - это плохой код.

(48) оптимален по памяти по скорости по читабельности?

(48) Тсссс.... Не плоди конкурентов. А то начнут сразу хорошо писать, хорошие специалисты подешевеют.

(49) По скорости (учитывая параллельно работающих), по читабельности. На память - похер.

(50) Заказчик, как правило, далек от этого.

а что важнее скорость чтения или скорость записи?

Я буду только счастлив, если все будут писать хороший, годный код. Работы - хоть попой жуй.

(53) Я чую подвох в вопросе.

(52) :) Это если повезло. Чаще бывает что состояние заказчика выражается в "а-а-а, ничего не работает". А при анализе оказывается 7-ми этажный CASE в условии соединения таблиц запросе по партиям, что при проведении выполняется. За то быстро и читабельно был написан.

(55) так и есть. нет потому что универсального правила

(57) Опыт-с.

(42) Ну вот ссылка мне на специалиста нужна. Не буду я дальше ссылки ничего получать (не получаю сейчас и не планирую).

Есть академическая разница между 1 и 2 (если считаем, что в обоих случаях объект записан):

1) Объект.Специалист

2) ВЫБРАТЬ
    ПланРабот.Специалист КАК Специалист
ИЗ
    Документ.ПланРабот КАК ПланРабот
ГДЕ
    ПланРабот.Ссылка = &Ссылка

(59) Есть.

1 вариант будет быстрее. Он будет мгновенен. Данные считаются из памяти сервера 1С. Потому что "Объект" - не ссылка.

(59) Можно измерить конечно, но мне кажется без разницы. Даже 1) скорее всего быстрее будет, т.к. "Объект" скорее всего уже в памяти. А для 2) нужно будет как минимум проверять а записан ли объект, а не модифицирован ли он.

(61) Думаешь для 1С доступно грязное чтение?

(62)А при чём здесь цвет чтения? У меня на форме прямо сейчас выбран специалист Иванов, а в базе записана предыдущая версия, где выбран "Петров". Что будет, если запросом специалиста получу и не проверю что объект не модифицирован?

(63) Будет выбран "Петров". Если "Иванов" был записан в твоей сессии и транзакция не завершена, то для тебя "Иванов", для других "Петров"

Поддерживаю парадигму ненужности преждевременной оптимизации. Совсем пошлый бвдлокод писать не стоит, но и выкладываться на всю оптимальности имхо излишне. Ибо не востребовано. Если есть понимание что вот здесь нагрузка со временем будет расти - да, пишем оптимально. Если хз - то и нефиг млрочиться .
Какой смысл строить сверхзвуковой лайнер если под него ВПП даже в перспективе нет...

Проблема скорее всего с тем, сколько данных гоняется между клиентом и сервером, а не в выборке данных на сервере.

(64) Ответ правильный, но я намекал на другое. Дело не в транзакции, она уже завершена. Дело в разнице данных в базе и на форме. Предположим, что Специалист выводится в печатную форму. Что скажет пользователь, видя в документе "Иванова", а в печатной форме "Петров"?

(58) А вот еще вариант: писать многопоточный вариант или ограничиться однопоточным?

(67) Ну разумеется кто же будет тебе по всем клиентам кричать что данные изменились. Объект перед записью проверяет версию в базе и если она изменилась то ой. Для актуальности данных обычно в печатной форме объект не используется.

(68) Конечно однопоточный в 95%. Серверу и так есть чем заняться при количестве активных пользователей >=числу ядер процессора.

(60)С Объектом понятно, это текущие данные, с которыми работаем. А если есть ТЗ, в ней есть поле ссылочного типа (пусть Номенклатура), то как быстрей будет обращение:
1) ТЗ.Номенклатура обрабатывается в цикле. Обращений через точку больше нет.
2) ТЗ помещаем в запрос, делаем соединение со справочником номенклатур и далее уже обходим это дело в цикле. Обращений через точку больше нет.

(69) Речь о другом совсем. Вопрос был как правильно получать данные  - через точку из формы или запросом из базы, зависит от контекста задачи. И то и то правильно разных случаях.

(71) А смотря что делать с этой ТЗ планируется. Если номенклатуру из ТЗ надо просто добавить в табличную часть, ну или если в той-же ТЗ всё нужное есть, то 1).
Если нужно получить какие-то связанные с номенклатурой данные - ставка НДС, цена закупки/продажи и т.д., то быстрее запросом, т.е. 2)

(72) Да это всё гадание на кофейной гуще. Разные алгоритмы подразумевают и различный объём пересылаемой информации. Пусть в начале проверит какой объём гоняется клиент -> сервер -> клиент при его слабых то каналах. Может там 80% проблемы и нужно искать способы уменьшения объёма передачи данных.

(73) просто когда столкнулся с тем, что при обращении ТЗ.Номенклатура, тянулся весь объект, почему-то. И Замер показывал 90% на строчке вида
Ном = ТЗ.Номенклатура.
Контекст серверный.
А подобное же обращение через запрос этого затыка не показывал (сам запрос тоже занимал что-то вроде 0,1%)

(74) А где написано что канал слабый?  
(75) Странно. Надо смотреть на ТЗ и на контекст алгоритма. В общем случае разницы то нет - запрос тоже можно выгрузить в ТЗ, сделать цикл обхода и будет "почти 1)".

(76) Да затупил, это другой топик.

(76) В том-то и соль. ТЗ простая, с одной колонкой, но при обращении к реквизиту ТЗ тянулся весь объект, а при обращению к результату запроса, только ссылка.
Сам алгоритм проще некуда. Получался некий объект, туда пихалась эта ссылка и объект записывался.
Но замер производительности показал вот такую вот загогулину. Основное время было на получение ТЗ.Номенклатура, а не на получение объекта и его запись.

(78) Может дело в самой платформе. Совместимость с 8.3.6.

(78),(79). Сомневаюсь, что из за платформы, но по конкретно этому примеру над смотреть живую базу, чтобы диагностировать. Повторюсь. ТЗ можно засунуть в запрос, результат выгрузить в ТЗ. Будет ровно та-же ТЗ. Поэтому, если в ТЗ есть все необходимые данные, то запрос это просто лишний код.

(80) А если попробовать просто на какой-нибудь другой базе, будет ли такое же поведение?
Просто у меня под рукой другой базы нет, проверить не могу. Хотелось бы живого подтверждения/опровержения такого поведения.

(81) Ну я же пишу, что описываемые проблемы, это не типовое поведение. Много где тем или иным способом получается ТЗ, а потом обрабатывается - и в регистры пишется и в ТЧ запихивается. Нигде на чтении ТЗ не замечал задержек.

+(82) * Много где = Много где в типовых конфигурациях.
Если сможешь повторить, то скорее всего найдешь причину задержки :)

(82) Да вот сам гадаю почему так было. Тот код давно потерялся, так что повторить не получится. На простой проверке результат показывает именно примерно одинаковый. В случае выгрузки в ТЗ, выгружается дольше, но читается из самой ТЗ быстрее, в случае выборки, выбирается быстрей, а читается немного дольше. Думал, что кто-то может уже сталкивался, вот и задал вопрос.

(84) + удалось только выяснить то, что при наличии большого количества записей, выборка быстрей, чем выгрузка в ТЗ.

(0) Специалист = Объект.Специалист, тут ничего такого нет, вот если обращение через 2 точки, это дурно. Например  СпециалистКод = Объект.Специалист.Код
По поводу второго вопроса, в принципе можно и через точку, платформа сама соединение сделает, но это дурной тон.

(86) По поводу второго, это только если в условии или соединении, а если в секции ВЫБРАТЬ, то весь объект затянет по самый не балуйся.

(84) Кроме самого выполнения запроса есть ещё время получения результата. Т.е. от момента "Выполнить" до фактического заполнения объекта-получателя данных проходит два времени - выполнение запроса в СУБД и перетаскивание данных с СУБД до клиента. Самый быстрый вариант из моей практики пока это:
ТабличнаяЧасть.Загрузить(Запрос.ВыполнитьВыгрузить());

(88) Это понятно, мне не понятно другое.
Вот пример, почему обращение к реквизиту строки ТЗ быстрей, чем к реквизиту результата выборки?

http://clip2net.com/s/3Nhmwj9

(89) перепиши на

Для Каждого Стр Из Тз Цикл
Ном=Стр.Номенклатура;
Выборка.Следующий();
Ном=Выборка.Номенклатура;
КонецЦикла;

(89) Разница как раз во времени передачи, о чём я пишу в (88). Конструкция
ТЗ = Запрос.Выполнить.Выгрузить();
Делает сразу две операции и выполняет запрос и получает всю выборку в объект "таблица значений". Поэтому оно занимает 16% относительно 2 % конструкции Выполнить.Выбрать. Т.к. тут только выполнение запроса, а передача данных происходит по мере "Следующий()" и обращению к выборке.

Вообще проценты не сильно объективно на мой взгляд. Более правильно смотреть итоговое время замкнутого по смыслу куска - от момента "надо заполнить" до "заполнено". А в твоём примере, скорее всего, итоговое время в секундах будет одинаковым.

(90) Переписал
http://clip2net.com/s/3Ni73tX
Все равно обращение к реквизиту текущего элемента выборки осуществляется медленней, чем к реквизиту строки.
Может это из-за того, что строка сразу помещается целиком в память и поэтому к ее реквизиту обращение быстрей, и поэтому же Для каждого отрабатывает медленней, чем Рез.Следующий(), так как текущий элемент Рез не помещается в память?

(91) Так я же такие куски и показываю. Они логически завершенные. Первый выполняется 55% времени, а второй 45%. Но может это из-за того что немного дольше делается Выгрузить(), так как еще создается и заполняется ТЗ?

(92)
Именно поэтому. Строка в памяти, а выборка ещё ползёт от СУБД. Но при работе с ТЗ "Для каждого..." добавляются ещё накладные расходы на работу с самой таблицей значений. Небольшие, но они есть.

Надо ещё учитывать "температуру"  выполнения запроса. Второй раз СУБД тот-же запрос выполняет сильно быстрее - всё в кэше. Попробуй местами поменять ".Выполнить" и ".Выгрузить", первое выполнение будет дольше. Я потому и пишу, что логически завершенные куски надо мерять. Т.е.  по хорошему надо две отдельных процедуры - одна через ТЗ, вторая через выборку. И сравнивать время выполнения.

(93) Так и думал, спасибо.

Для "температуры" выполнения запроса, замер производительности я делал на втором запуске этой обработки, поэтому и предполагаю, что выполняется все примерно одинаково. Ну или можно было сперва выполнить поместить куда-то, а потом уже выгрузить и выбрать.

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

Спасибо за интересное общение.