В базе сделана куча проверок, где идет обращение к реквизитам через точку.
Например, Заказ.Договор.Владелец.ИНН

Это съедает скорость работы. Одна проверка через такое обращение занимает 38%.

Вопрос. Как это можно оптимизировать? Переводить на запросы - долго и не факт, что даст скорость работы.

1) Написание общей функции повторного использования, которая делает обращение к промежуточным данным (чтобы минимизировать вероятность получения устаревших данных). Примерно так:
ПовтИсп.ЗначениеРеквизита(Заказ,"Договор.Владелец").ИНН

есть еще какие-то варианты?

переделывание на формат БСП
ЗначениеРеквизитаОбъекта и подобные функции

(1) а ЗначениеРеквизитаОбъекта() умеет получать данные через точку?

1) предварительно получить все необходимые реквизиты перед проверками;
2) перейти на табличную модель получения данных, т.к. у тебя наверняка обращения к составным типам присутствуют (вижу "Владелец" в примере), что влечёт за собой избыточные внутренние соединения;
3) 38% - это данные замера производительности? Может проблема в конкретной строчке кода, где идёт обращение к реквизитам составного поля?

(0) Можно укоротить разыменование:

Заказ.Договор.Владелец.ИНН -> Заказ.Контрагент.ИНН
:)

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

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

"Переводить на запросы - долго и не факт, что даст скорость работы."

скорость работы даст в любом случае

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

Если предположить, что многие данные уже храняться в оперативной памяти, то с вероятностью 146% можно сделать вывод, что причина падения производительности в одной из строк рукоблудного кода :)

(0) посмотри на картинку у меня в профиле, это результат работы 1С-ников таких как ты

(7) Милота то какая.

А я вот знаю про что ТС-говорить, это регистры покупатели и поставщики? туда не пишется контрагент, а только договор, оптимизировать получится только добавив контрагента в регистр, прописать его туда в модулях проведения доков, свернуть базу, оставшиеся доки перевровести, тугие отчеты переписать, точнее дописать выборки по контрагенты

(9) дикость какая.

(7) Руки-то целы?

(0) Закешировать. Способов вагон.

(10) Всмысле?

(13) Нет ничего страшного прицепить через точку Владельца Договора.

(14) при больших объемах, иногда до 60% времени сжирает Владелец()

Заказ.Договор.Владелец.ИНН

Почему не проверять ИНН перед записью контрагента?

(1) что за формат БСП? ЗначениеРеквизитаОбъекта и подобные функции
о_О

(17) ЗначениеРеквизитаОбъекта() - это БСП-шная функция.

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

(19) А если данные изменятся, т.е. кэш протухнет?

(20)
Есть такая проблема. Только вчера в УХ ответственных лиц через модуль повторного использования получал. Заполнил регистр и долго втыкал, почему пусто в отчете.
Зависит от продолжительности проверки.

(0) Запросами не?

(0) Для таких целей в модуле ОбщегоНазначения есть целая кучка функций:
ЗначенияРеквизитовОбъекта(Ссылка, Знач Реквизиты, ВыбратьРазрешенные = Ложь)
ЗначениеРеквизитаОбъекта(Ссылка, ИмяРеквизита, ВыбратьРазрешенные = Ложь)
ЗначенияРеквизитовОбъектов(МассивСсылок, ИменаРеквизитов, ВыбратьРазрешенные = Ложь)
ЗначениеРеквизитаОбъектов(МассивСсылок, ИмяРеквизита, ВыбратьРазрешенные = Ложь)


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

Если подходить глобально, то верно написано в (19). Но для этого надо значительно больше переписать кода.

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

(19) всё уже закэшировано до нас. Вы и правда думаете, что платформа у себя не кэширует?

(24) Такой глобальный пересмотр методики учета для большинства типовых просто нереален. Или будет означать отказ от дальнейшего обновления от поставщика.

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

(7) запрос-то выполнился?

(26) Типовые от 1С и не нуждаются в подобной переделке, т.к. спроектированы по большей части хорошо. В отличие от отраслевых поделок франчей, вот уж где трэш и угар.

(23) Я использую обертку повторновозвращаемых над ЗначениеРеквизитаОбъекта

помогает не городить свой кэш при групповых массовых обработках

(29) ха^3

(31) да ладно, там даже получение остатков по партиям уже поправили.

(26) можно расширениями все сделать, даже не дожидаться режима совместимости)

(31) как тебе такое: https://forum.infostart.ru/forum34/topic180290/#message1904747

(34) Ну если только КЛАДРы жать.

(34) Ставлю дайм, это очень оценили на партнерском

А как бы годно было бы дать возможность жать справочники и РС

(34) для тех кто держит тестовые базы в продуктиве (да-да, я про тебя), наверно актуально

(38) денег нет, но мы держимся

(20) если это принципиально, то и результат проверки через точку может протухнуть.
(27) кэш объектов.
Заказ.Договор.Владелец.ИНН = Заказ.ПолучитьОбъект().Договор.ПолучитьОбъект().Владелец.ПолучитьОбъект().ИНН.

все полученные объекты будут закэшированы платформой.

(40) если совсем принципиально, можно управляемую блокировку на цепочку ссылок повесить...

(34) а индексы че не пожал?

(42) пожал

(39) у вас еще и сервер 1С вместе с сервером СУБД на одной железке?

(44) там еще и железку альтернативные выбирали... ну хоть на ssd...

(43) я слепой. увидел.

(41) тогда и транзакцию прицепом) А проверять реки на что-то там, скорее всего, можно полностью в запросе

(48) таки ты прав

(46) Мы выключили виртуализацию.

(50) ты не поверишь, но на этом серваке еще есть и виртуалка с какой-то хуйней. Деть некуда, см (39), но хоть нагрузки не дает хоть как-то ощутимой.

*фигнёй

(34) скрипт можно еще доработать. боле умным сделать.

(53) например? смотреть соотношение чтения записи и estimated сжатие?

ИТ директор , см Что быстрее соединение или В бывает еще хуже :)

(54) ага. это читал? https://msdn.microsoft.com/en-us/library/dd894051(v=sql.100).aspx

я хотел наваять, но ленюсь.

(56) супер. на выходных добью скрипт :)

вытащить все данные запросом может потребоваться еще больше времени т.к надо соединять все таблицы

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

*через точку

(59) а если объект содержит таб части, то (раньше - так точно) делает это в микротранзакциях