Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Рекомендую изучение подобной темы начинать с описания работы кэшей на ИТС:
- Объектный кэш
- Транзакционный кэш
- Кэш представлений ссылок
Также полезно техножурналом смотреть сначала запросы модели базы данных (SDBL), т.к. в них меньше "мусора" и лучше видна логика работы платформы.
- Объектный кэш
- Транзакционный кэш
- Кэш представлений ссылок
Также полезно техножурналом смотреть сначала запросы модели базы данных (SDBL), т.к. в них меньше "мусора" и лучше видна логика работы платформы.
Статья как уже заметил (1) не достаточно объективная.
Что решит обычный разработчик прочитав ее?
"Получать через точку не выгодно".
А на самом деле зачастую выгоднее получать через "." особенно если объект это какой то НСИ который редко меняется.
Т.к. с высокой долей вероятности значение всех полей уже есть в кэше и чтение из БД не потребует чтения из базы.
В то время как использование функций БСП гарантированно приводит к чтению данных.
Так например обращение к реквизиту формы через "." с вероятностью 90% приведет к чтению кэша а не к получению данных из ИБ.
Думаю что для полноты статьи нужно провести эксперименты с учетом кэширования.
Что решит обычный разработчик прочитав ее?
"Получать через точку не выгодно".
А на самом деле зачастую выгоднее получать через "." особенно если объект это какой то НСИ который редко меняется.
Т.к. с высокой долей вероятности значение всех полей уже есть в кэше и чтение из БД не потребует чтения из базы.
В то время как использование функций БСП гарантированно приводит к чтению данных.
Так например обращение к реквизиту формы через "." с вероятностью 90% приведет к чтению кэша а не к получению данных из ИБ.
Думаю что для полноты статьи нужно провести эксперименты с учетом кэширования.
(16) Уот так уот, оказывается методами БСП невыгодно получать реквизит. Нонсенс!
Давайте поможем Даше получить оптимальнее контрагента из ссылки на заказ.
Вариант 1. Через точку. При этом считаются все реквизиты, табличные части из СУБД. В лучшем случае из кеша. Но в кеш то надо еще получить!
Вариант 2. Управляемый. С помощью запроса за 3 мс получить значение нужного реквизита без мусора. Гарантировано всегда быстро.
Ах да, писатели типовых ведь сплошь стажеры, придумали фигню, лучше бы всю базу в кеш затолкали, а чего, быстро же будет!
Давайте поможем Даше получить оптимальнее контрагента из ссылки на заказ.
Вариант 1. Через точку. При этом считаются все реквизиты, табличные части из СУБД. В лучшем случае из кеша. Но в кеш то надо еще получить!
Вариант 2. Управляемый. С помощью запроса за 3 мс получить значение нужного реквизита без мусора. Гарантировано всегда быстро.
Ах да, писатели типовых ведь сплошь стажеры, придумали фигню, лучше бы всю базу в кеш затолкали, а чего, быстро же будет!
Как бы известно, что если по ссылке получаешь реквизит, например:
ЗаказСсылка.Номер
то из СУБД считывается целиком объект со всеми реквизитами и табличными частями
поэтому, если нужно считать 1 или несколько реквизитов из сложного объекта, типа документа, то рекомендуют делать это через Запрос
ЗаказСсылка.Номер
то из СУБД считывается целиком объект со всеми реквизитами и табличными частями
поэтому, если нужно считать 1 или несколько реквизитов из сложного объекта, типа документа, то рекомендуют делать это через Запрос
В БСП с целью оптимизации обращения с СУБД как раз и используется
ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, ИмяРеквизита, ВыбратьРазрешенные = Ложь).
Не пренебрегайте этой функцией и, тем самым, сократите время выполнения кода.
ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, ИмяРеквизита, ВыбратьРазрешенные = Ложь).
Не пренебрегайте этой функцией и, тем самым, сократите время выполнения кода.
Попытался. В самописную конфу вставил функцию из БСП.
Задача: приСозданииНаСервере() в реквизит "кладовщик" прописать значение реквизита "сотрудник" справочника "Пользователи". Ссылка на пользователя находится в параметре сеанса "ТекущийПользователь":
p.s. неудачно скриншоты получились.
Там где обращение тупо кладовщикВыдачи = ПараметрыСеанса.ТекущийПользователь.Сотрудник время 0,003309, а там где КладовщикВыдачи = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ПараметрыСеанса.ТекущийПользователь,"Сотрудник"); время 0,039332 - ровно на порядок. Может пример неудачный?
Задача: приСозданииНаСервере() в реквизит "кладовщик" прописать значение реквизита "сотрудник" справочника "Пользователи". Ссылка на пользователя находится в параметре сеанса "ТекущийПользователь":
p.s. неудачно скриншоты получились.
Там где обращение тупо кладовщикВыдачи = ПараметрыСеанса.ТекущийПользователь.Сотрудник время 0,003309, а там где КладовщикВыдачи = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ПараметрыСеанса.ТекущийПользователь,"Сотрудник"); время 0,039332 - ровно на порядок. Может пример неудачный?
Прикрепленные файлы:
(18) для случая Сообщить(Валюта) точно не считывает - в этом случае платформа понимает, что нужно получить только представление объекта, оно кэшируется. А вот для случая преобразования в строку - это вопрос, но он по сути не имеет смысла, т.к. этот код в любом случае методическая ошибка.
(24) Планирую заняться подобными исследованиями на 8.3.16.1063.
Кому что интересно - пишите.
Пока что в ближайших планах - проверить вычитывание ТЧ и стандартные реквизиты (код, номер, дата).
Прошу не писать про кеширование - по максимуму буду избегать его использование.
Кому что интересно - пишите.
Пока что в ближайших планах - проверить вычитывание ТЧ и стандартные реквизиты (код, номер, дата).
Прошу не писать про кеширование - по максимуму буду избегать его использование.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|