Оптимизация обращений к реквизитам объектов через точку #811052

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

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

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

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

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

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

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

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

Милота то какая.

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

дикость какая.

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

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

Всмысле?

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

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

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

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

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

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

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

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

Запросами не?

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

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

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

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

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

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

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

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

ха^3

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

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

как тебе такое:

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

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

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

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

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

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

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

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

пожал

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

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

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

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

таки ты прав

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

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

*фигнёй

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

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

, см бывает еще хуже :)

ага. это читал? я хотел наваять, но ленюсь.

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

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

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

*через точку

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