Единый семинар «1С» для бухгалтеров и руководителей

Ускоряем 1С: модули с повторным использованием возвращаемых значений

Программирование - Практика программирования

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

В чем проблема

Часто нам приходится по ходу исполнения программы получать значения, которые хранятся в базе данных и не меняются годами. Яркий пример - значения констант. Отчасти, можно причислить сюда же поиск элемента справочника или узла плана обмена по коду, получение значений реквизитов объектов по ссылке.

Не думая, "на лету" такие задачи решаются конструкциями вида:

Если ДатаДокумента > Константы.ДатаНачалаПримененияПостановления1137.Получить() Тогда

В результате, каждый раз когда выполняется этот код - происходит "дерганье" базы данных.

Программисты более щепетильно относящиеся к своему коду, выполняют один запрос к базе данных, кэшируя все данные которые им понадобятся, однако такой подход не всегда приводит к желаемой разгрузке БД:

  1. Цикл выполнения кода может быть неявным (например, групповое перепроведение документов)
  2. Получить строгий набор данных (не больше и не меньше), которые потребуются позже, иногда затруднительно или вовсе невозможно.
  3. Кэшированные значения требуется использовать в разных вызовах/формах

Модуль с повторным использованием возвращаемых значений

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

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

Возвращаемые значения, естественно, кэшируются в разрезе значений переданных параметров, т.е. при выполнении кода

Узел1 = НашМодуль.ПолучитьУзелОбменаСБухгалтерией("0001");
Узел2 = НашМодуль.ПолучитьУзелОбменаСБухгалтерией("0002");

, оба вызова действительно приведут к выполнению соответствующей процедуры и вернут разные ссылки, а при последующих попытках получить узел с кодом 0001 или 0002 - будут возвращаться соответствующие узлы без вызова процедуры и, как следствие, базы данных.

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

Чего делать нельзя

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

Возвращаемое значение при этом может быть любого типа.

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

Баг или фича от 1С

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

ЗначениеСтруктура1 = НашМодуль.ПолучитьСтруктуруЗначенийРеквизитов(СсылкаНаОбъект);

ЗначениеСтруктура1.Наименование = "Новое наименование";

ЗначениеСтруктура2 = НашМодуль.ПолучитьСтруктуруЗначенийРеквизитов(СсылкаНаОбъект);

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

Что делать при изменении закэшированных данных

Есть всего лишь один "легитимный" метод обработать ситуацию с изменением закэшированного значения в базе данных. Это метод ОбновитьПовторноИспользуемыеЗначения(). Будут сброшены значения всех функций по всем параметрам всех модулей. Обновить по конкретным значениям параметров / функциям / модулям нельзя.

Соответственно, из-за такого волюнтаристского подхода, пользоваться этой функцией необходимо крайне осмотрительно: вся система после его использования какое-то время будет работать существенно медленнее.

Посягаем на святое: пишем запрос в цикле

Кроме очевидных вариантов использования функций с повторным использованием возвращаемых значений, есть немало интересных, универсальных, нестандартных подходов, среди которых:

  • Написание универсальных процедур, возвращающих реквизиты произвольных ссылок (есть в БСП)
  • Написание процедур, возвращающих значения констант по имени константы (есть в большинстве типовых)
  • Возврат "чуть большего" объема данных, чем необходимо ради уменьшения количества вызовов (напр. если требуется получить курсы сразу нескольких валют, имеет смысл вызывать функцию по дате без отбора валюты, получить курсы всех валют и далее "разбираться на месте" какая из валют в настоящий момент нужна)
  • Написание процедуры, выполняющей запрос с кэшированием результата (входящими параметрами при этом будут текст запроса и пара-тройка имен и значений параметров)

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

  1. Количество различных значений входящих параметров, которые встретятся внутри цикла небольшое и подавляющее большинство сочетаний с высокой долей вероятности было получено ранее в этом сеансе.
  2. Заранее получить строгий набор сочетаний значений входящих параметров, которые встретятся в цикле затруднительно, а получение значений для всех возможных сочетаний значений входящих параметров приведет к считыванию большого объема данных из БД

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

См. также

Комментарии
1. в п (panvartan) 04.09.17 17:26 Сейчас в теме
Используем утечки памяти по назначению
2. kolya_tlt kolya_tlt (kolya_tlt) 11 04.09.17 17:55 Сейчас в теме
Имеет смысл кэшировать данные, полученные из базы данных, внешних источников данных или путем сложных (ресурсоемких) вычислений. Причем в ряде случаев, даже значения, полученные из базы данных, не стоит кэшировать, если выгода от их кэширования – неочевидна.

https://its.1c.ru/db/v8std#content:-2145782923:hdoc
3. Арман Б. (Dream_kz) 27 04.09.17 18:41 Сейчас в теме
Баг это или фича непонятно, но знать о нем не помешет


Просто особенность, первым вызовом получим ссылку на элемент в области памяти, поменяем ее значение, а вторым вызовом получим ссылку на эту же область памяти, естественно что значение по ссылке уже будет измененное.

Статья хорошая, но не раскрыты собственно сами модули, отличия при хранении на время вызова и на время сеанса, время хранения значений на сервере на время сеанса (около 6 минут), а так же то, что это не панацея, и допустим от получения булевых констант таким образом, выигрыша будет мало.
nvv1970; Artem-B; mytg; Yashazz; vovan_victory; JohnyDeath; Sergant666; DimaP; ivant; alexch8; +10 Ответить
5. Анатолий Бритько (headMade) 135 04.09.17 20:39 Сейчас в теме
(3)в чем будет принципиальное отличие при чтении и кешировании значений булевых констант?
6. nicolas eliseev (nicxxx) 167 04.09.17 21:26 Сейчас в теме
(5)Очевидно же, что чтение будет обращаться к таблице констант в базе, а использование кэша заменяет обращение к базе обращением к памяти, что несколько быстрее, раз в 100 примерно.
9. Александр (chea06) 130 05.09.17 09:56 Сейчас в теме
(6)не факт
"Причем в ряде случаев, даже значения, полученные из базы данных, не стоит кэшировать, если выгода от их кэширования – неочевидна. Например, не стоит кэшировать константы (объект метаданных) примитивных типов, поскольку часто они привносят лишь незначительную долю от общего времени выполнения ресурсоемкой операции" ©
10. Арман Б. (Dream_kz) 27 05.09.17 10:49 Сейчас в теме
(5) Принципиальных отличий не будет, но как сказал я ранее, и дали ссылку в (9) эффекта будет мало.
44. Uladzimir - (nvv1970) 11.11.17 09:55 Сейчас в теме
(3) Звезда не заработана.
Время жизни кэшированных значений - это важнейший момент, отличающий данный механизм от глобальной переменной используемой как КЭШ.
На ИТС кажется были следующие значения: 20 минут от создания или 6 минут от последнего чтения из кэша.
...кэш не хранит данные вечно. Закэшированное значение будет удалено из кэша через 20 минут после вычисления или через 6 минут после последнего использования (в зависимости от того, что наступит раньше*). Кроме этого значение будет удалено при нехватке оперативной памяти в рабочем процессе сервера, при перезапуске рабочего процесса и при переключении клиента на другой рабочий процесс. Поэтому если никто "не успел" воспользоваться данными из кэша, то этот ресурс был потрачен зря.


А самый большой косяк автора - это не рассказать где живут кэши! И что будет при использовании "фичи".
Чтобы не быть голословным - еще раз перепроверил свои знания практическим примером. Докладываю:
Повторяемый серверный модуль с вызовом сервера имеет 2 кэша: как на сервере, так и на клиенте!!! Если самому "установить" в закэшированную структуру значение, то оно запишется в кэш только там где его присвоили (на клиенте или на сервере). Т.о. на клиенте и на сервере после такой махинации будем из кэша получать разные значения.
Deslime; Daynestro07; pvlunegov; sashocq; mxs89; Serj1C; +6 Ответить
4. Александр Анисков (vandalsvq) 844 04.09.17 18:57 Сейчас в теме
Это не баг, скорее все таки фича. На прошлой партнерке 1С рассказывали, объекты возвращаются по ссылке, т.е. не копия структуры, массива и т.д., а ссылка на область памяти по сути (косвенно можно сделать такие выводы также из статьи про системы диагностики из "зазеркалья" тынц).

Так что, не рекомендуют так обновлять - что ж поделать, не будем. Ну если только совсем чуть-чуть, ну самую капелюшечку )))))
39. Caponid V (caponid) 10.11.17 15:23 Сейчас в теме
(4) Это не баг, и таки не фича - это способ выстрелить себе в ногу))).

Если хочется возвращать наборы значений - то логичней использовать "фиксированные" - Фиксированная структура и т.д.
7. Игорь Дайнеко (Dnki) 05.09.17 07:49 Сейчас в теме
Про механизм знаю, но пользуюсь.
* Первая причина: неудобно 1С сделала признак - на весть модуль. Нужно было бы сделать директиву к функции, аналогично "export". По-моему, сам бог велел ввести такое свойство, явно написанное программистом, а не легко устанавливаемая/ снимаемая птичка. Я поясню: написал я модуль "РаботаСЧемТО". В нем собраны ф-ии по одной теме. Из них только одна нужна с кэшированием. Ясно дело, можно разбить, но краше от этого программа не будет.

* Механизм очень уж неявный. Я не знаю, когда сбросится кэш. Самому дать команду сброса - сбрасывается все. Короче, все что не написано программистом, вызывает сомнение в работе, особенно в след. релизах. Когда мне понадобилось, я сам написал. Например, кэш курсов валют сбрасываю в начале формирования отчета. Некоторые данные, часто используемые, но практически не меняемые, читаются в глобальный объект только при запуске.

* В задаче повторных значений лучше бы 1С решило для меня такую задачу: по анлогии с "С" иметь параметр объявления переменных Static. Такие переменные, являясь переменными процедуры, сохраняются в памяти между вызовами процедуры.Вот это был бы классный кэш!
baton_pk; sergelemon; Yashazz; mixsture; shard; PowerBoy; mrDSide; +7 Ответить
20. Александр Соколов (mefalcon) 14 06.09.17 10:04 Сейчас в теме
(7)>>Я поясню: написал я модуль "РаботаСЧемТО". В нем собраны ф-ии по одной теме. Из них только одна нужна с кэшированием. Ясно дело, можно разбить, но краше от этого программа >>не будет.

Именно так 1С делает в типовых решениях, добавляя в конец имени модуля, отражающую предметную область использования, суффикс "ПовтИсп"
https://stimul.kiev.ua/materialy.htm?a=pravila_sozdaniya_obshchikh_moduley
21. Сан Саныч (herfis) 213 06.09.17 10:35 Сейчас в теме
(20) Более того - это зафиксировано в стайл-гайде 1С по именованию общих модулей.
В принципе - не такое это уж и неудобство. Ну, то что нужно отдельный модуль для этого. Даже в чем-то лучше, чем на уровне сигнатуры функции это указывать, как в (7) предлагали. Да, модуля плодятся, но в клиент-сервере их и так плодить приходится. А лучше тем, что прямо по вызову функции видно, что она кэшируемая. В клиент-сервере если боль-менее развесистую подсистему делаешь, то начинается
Клиент, КлиентСервер, Сервер, ВызовСервера, КлиентПовтИсп, СерверПовтИсп - шесть модулей как с куста.
А могут еще быть ПолныеПрава и Глобальный (но за глобальные надо расстреливать, я считаю).
8. Sergey Andreev (starik-2005) 1224 05.09.17 09:47 Сейчас в теме
"Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" (с) Шекспир.

К чему это я? А к тому, что иногда (и даже часто) некоторые моменты при кешировании объектов таким способом могу привести к непредсказуемым последствиям. В частности, от длины "ключа" может зависеть жизнеспособность кешированного объекта при последующем его обновлении. Т.е. типа получаете объект тОбъект = ОбщМодПовтИсп.ПолучитьОбъект("ХХХУУУZZZ"), а он вам так раз....
11. Сан Саныч (herfis) 213 05.09.17 10:57 Сейчас в теме
Хоть и РТФМ, но плюсанул. Может, кому-то статья поможет начать использовать эту функциональность.
Сам использую достаточно широко - в ряде случаев помогает одновременно и упростить код и повысить его эффективность.
Единственный совет - хорошо подумайте, точно ли кэшируемая информация является условно-постоянной (является ли критичным доступ к обновленным в течение сеанса данным).
12. Антон Локтионов (Anton64) 148 05.09.17 13:18 Сейчас в теме
Ссылку нельзя передавать параметром?
13. Сан Саныч (herfis) 213 05.09.17 13:29 Сейчас в теме
14. Сергей Старых (tormozit) 4545 05.09.17 13:32 Сейчас в теме
Неплохо бы еще не только про "на время сеанса" но и про 20 минутное время жизни значений в кэше упомянуть. Эта особенность на некоторые способы использования влияет сильно.
16. Сан Саныч (herfis) 213 05.09.17 14:07 Сейчас в теме
(14) Кэш, как и обещано, живет до конца сеанса. Через 20 минут без использования он просто на диск откочует. И "неожиданности" тут возникнут только с мутабельными значениями, которые невозможно корректно сериализовать. То есть проблемы возникнут, если пытаться использовать кэш как хранилище глобальных серверных переменных произвольного типа. Но да - эту особенность упомянуть стоит однозначно.
Можно, например, инициализированный COM-объект так держать в памяти сервера. В большинстве случаев ничего страшного, если он пересоздастся после долгого неиспользования. Я по-дефолту так с сервера всякие сторонние соединения поднимаю. Если же пытаться так хранить мутабельные промежуточные результаты, которые терять нельзя, то придется обеспечить их "дергание", чтобы они не потерялись при попытке сериализации. Но это уже совсем изощренные костыли, которых стоит избегать. Лучше оставаться в рамках stateless-модели сервера, пусть и с некоторой потерей эффективности.
17. Сергей Старых (tormozit) 4545 05.09.17 15:11 Сейчас в теме
(16)
Кэш, как и обещано, живет до конца сеанса.

Ошибаешься. Тут уже привели ссылку на ИТС. Почитай https://its.1c.ru/db/v8std#content:-2145782923:hdoc
18. Сан Саныч (herfis) 213 05.09.17 15:27 Сейчас в теме
(17) Смущает примечание "раздел обновлен". Сдается мне, ранее на ИТС я читал совсем другое.
19. Сан Саныч (herfis) 213 05.09.17 15:35 Сейчас в теме
(17) Хотя и в руководстве разработчика на ИТС тоже самое написано...
Не хотелось бы принимать во внимание свой маразм, но видимо придется :)
35. Uladzimir - (nvv1970) 07.09.17 22:02 Сейчас в теме
(17) Перечитал это еще раз (процитирую)
Закэшированное значение будет удалено из кэша через 20 минут после вычисления или через 6 минут после последнего использования (в зависимости от того, что наступит раньше*). Кроме этого значение будет удалено при нехватке оперативной памяти в рабочем процессе сервера, при перезапуске рабочего процесса и при переключении клиента на другой рабочий процесс. Поэтому если никто "не успел" воспользоваться данными из кэша, то этот ресурс был потрачен зря.
* Примечание: конкретные цифры могут варьироваться в зависимости от используемой версии платформы 1С:Предприятие.

На какой-то из недавних версий платформы пытался это поведение протестировать. Ставишь точку в повторяемом модуле. Провалился в модуль - кэш очистился, нет - еще жив.
Любопытно, что четких временных границ для "последнего использования" не оказалось. Как-то хаотично очистка кэша срабатывала: могло и по 10, и по 20 минут не очищаться при полном бездействии. Но то что очистка происходит - это факт. И это прекрасно )) С содроганием вспоминаю кэш в глобальной переменной.

ПС: еще не раскрыта тема и приведены примеры "кэша на вызов". Такой вид почти не используется. А между тем тоже стоит о нем помнить. Хватает специфических сложных алгоритмов, когда такой кэш незаменим.
15. xReason (xReason) 05.09.17 13:39 Сейчас в теме
Можно возвращать данные с типом ФиксированнаяСтруктура, ФиксированныйМассив и т.д.
Тогда фича от 1С в виде изменяемого значения не будет работать
32. Павел Одинцов (Darklight) 07.09.17 09:23 Сейчас в теме
(15)Возвращать-то можно любое значение. Но, принимать как параметр.... в повторно используемую функцию можно значение типа "Структура". Но НЕЛЬЗЯ типа "ФиксированнаяСтруктура" - вот такой идиотизм. Конечно преобразования "Структура" <-> "ФиксированнаяСтруктура" делается легко - но для повторного использования важна идентичность входных параметров - а тут она теряется!
Поэтому, лично я предпочитаю вот так (привожу в упрощённом виде) создавать структуры - когда нужна их идентичность (ну и не изменять их потом):

//Размещено в модуле повторного использования
функция Структура(ПараметрыСтр, п1=null,п2=null,...здесь ещё 96 таких параметра...,п99=null,п100=null)
    возврат Новый Структура( ПараметрыСтр, п1,п2,...здесь ещё 96 таких параметра...,п99,п100);
КонецФункции


Такой подход "гарантирует", что где-то 20 минут структура будет идентична, и её "без опаски" можно дальше передавать как входной параметры в другие повторно используемые функции.
Конечно, есть и другие варианты достичь идентичности.
22. Николай Нагачевский (bruho) 06.09.17 15:02 Сейчас в теме
Для того, чтоб "сбросить" значения в методе с повторным использованием использую необязательный параметр, в который передаю УИ. Но подходит только для тех случаев, когда явно указываешь вызов с заполненным необязательным параметром.

Функция МетодСПовторнымИспользованием(ОбновитьЗначение = Неопределено) Экспорт 
	
	Время = ТекущаяДата();
	
	Возврат Время;
КонецФункции

//Время вернет из первого обращения к методу
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = Строка(МетодСПовторнымИспользованием());
Сообщение.Сообщить();


//Время вернет текущее
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = Строка(МетодСПовторнымИспользованием(Строка(новый УникальныйИдентификатор)));
Сообщение.Сообщить();



Показать
23. г. Казань Рустем Гумеров (Rustig) 836 06.09.17 15:11 Сейчас в теме
(0) я суть статьи не понял. рабочие примеры есть для понимания?

уже писал на форуме, прошло не замеченным - то что сейчас разработчики типовых 1с применяют - сильно огорчает. вот пример:

Столкнулся в УТ 10.3 с такой проблемой - в УТ 10.3 появился механизм ПравилаВыборочнойРегистрацииОбъектов (константа),

который не позволяет переименовывать типовые реквизиты документов.

Я переименовал в документе ПКО реквизит Основание (Тип Строка), потому что он некорректно заполняется при заполнении на основании другого документа (стандартный параметр Основание процедуры ОбработкаЗаполнения()).

...Срабатывает процедура ОбработкаЗаполнения, в которую передается параметр Основание (тип ДокументСсылка). В конце концов реквизит документа Основание и параметр Основание пересекаются и дают отрицательный эффект.

Я переименовал этот реквизит в ОснованиеСтрока - теперь у меня элементарно не проводится документ, выходит ошибка здесь:

Функция ПолучитьТаблицуРеквизитовРегистрацииШапкиДоИзменения(Объект, СтрокаТаблицыРеквизитовРегистрации)

ТекстЗапроса = "
|ВЫБРАТЬ " + СтрокаТаблицыРеквизитовРегистрации.РеквизитыРегистрации
+ " ИЗ " + СтрокаТаблицыРеквизитовРегистрации.ИмяОбъекта + " КАК ТекущийОбъект
|ГДЕ
| ТекущийОбъект.Ссылка = &Ссылка
|";

Запрос = Новый Запрос;
Запрос.Текст = ТекстЗапроса;
Запрос.УстановитьПараметр("Ссылка", Объект.Ссылка);

Возврат Запрос.Выполнить().Выгрузить();

КонецФункции

, в запрос тащится СтрокаТаблицыРеквизитовРегистрации.РеквизитыРегистрации, который содержит следующие поля:

Организация, ВидОперации, Контрагент, ДоговорКонтрагента, ВалютаДокумента, СуммаДокумента, ПринятоОт, Основание, Приложение, Комментарий, ДокументОснование, СтатьяДвиженияДенежныхСредств, СтавкаНДС, НомерЧекаККМ, ПометкаУдаления, Проведен, Номер, Дата, Ответственный, ОтражатьВБухгалтерскомУчете

То есть таким механизмом разработчики ут 10.3 не позволяют переименовывать типовые реквизиты. Хм, думаю это неправильно.

может я не туда пишу - поправьте - но это своего рода кэширование - хранение информации о жесткой структуре метаданных конфигурации которую как будто теперь нельзя изменять - валятся родные механизмы
24. Гази Кушкунов (gmkushkunov) 06.09.17 15:42 Сейчас в теме
(23) Здравствуйте.

По поводу жесткой структуры не совсем понятно, раз вы переименовали стандартный реквизит значит структура нежесткая, просто надо переписать код где идет обращение к этому реквизиту. Мне кажется Вы сами никогда не программировали в связке СУБД. Если Вы создали в СУБД таблицу а в ней поля, назвали их как то и написали программу, в которой идет обращение к этой таблице и ее полям (т.е. к их именам), протестировали и дали заказчику полностью рабочую программу, а заказчик в свою очередь переименовал стандартные поля в Вашей таблице не исправляя кода программы, где идет обращение к переименованным полям и обнаруживает, что программа перестала работать (выдает ошибки и т.д.) и начинает Вам жаловаться, что Вы не правильно составили программу, как Вы на это посмотрите?

P.S. на самом деле Вы не в ту тему пишите.
sergelemon; Rustig; +2 Ответить
25. г. Казань Рустем Гумеров (Rustig) 836 06.09.17 16:40 Сейчас в теме
(24) я понял вас: пугает что этот список реквизитов засунули в константу с типом Хранилище.

обычно когда меняют наименование реквизита, прогоняют глобальным поиском места где встречается этот реквизит, и везде поправляют название.

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

ну и кто так кодит?

вердикт - что-то намудрили в УТ с механизмами версий, оттуда проблемы происходят
26. г. Казань Рустем Гумеров (Rustig) 836 06.09.17 16:47 Сейчас в теме
(24) я вот не пойму обсуждаемую здесь тему с кэшированием без примеров - какую конкретную задачу пытается решить автор?
27. Сан Саныч (herfis) 213 06.09.17 17:09 Сейчас в теме
(26) Автор не про конкретную задачу, а про инструмент.
Если хочется живых примеров - откройте список общих модулей любой современной типовой и глядите в модуля, где в конце "ПовтИсп" в названии.
sergelemon; Rustig; +2 Ответить
28. г. Казань Рустем Гумеров (Rustig) 836 06.09.17 17:29 Сейчас в теме
(27) ок, понятно
а зачем так сложно придумали?
столько модулей развели - в чем суть?
29. Сан Саныч (herfis) 213 07.09.17 07:03 Сейчас в теме
(28) Жертвы на алтарь возможности работать через браузер.
30. г. Казань Рустем Гумеров (Rustig) 836 07.09.17 08:07 Сейчас в теме
(29) где-нибудь можно об этом прочитать подробнее?
31. Сан Саныч (herfis) 213 07.09.17 09:05 Сейчас в теме
33. Дмитрий Д (profiprog1c) 157 07.09.17 12:49 Сейчас в теме
Статья полнейшая глупость. Если бы автор реально занимался замерами работы производительности, то он бы знал, что получение константы методом:
Константы.ЛюбаяКонстанта.Получить()
занимает тысячные доли процента, от времени выполнения реального кода.
А уж если и нужно в коде часто использовать данные этой константы, то пишем:
НашаПеременная = Константы.ЛюбаяКонстанта.Получить()
и дальше использ-уем НашаПеременная
Самые затраты операции при работе кода - это запросы и вот там нужно оптимизировать.
34. Uladzimir - (nvv1970) 07.09.17 21:44 Сейчас в теме
(33) Это так, экономия на спичках, непонимание которой, умноженное на тысячи, сотни тысяч обращений к СУБД в сотнях или тысячах сеансов сделают свое черное дело. Конечно СУБД тоже не дура - сама что-то закэширует. Но, гуру подскажут точно, наверняка это генерирует лишние соединения к СУБД, количество которых в какой-то момент тоже может быть критичным.
Мораль такова: если нужно переходить дорогу на зеленый свет - давайте это делать всегда, даже если дорога пустая, а не только когда это кому-то нужно. Если есть инструмент, то, как минимум, им нужно хотя бы уметь пользоваться. А лучше пользоваться всегда и по назначению.
37. Сергей Назаренко (Hobbit_Jedi) 10.11.17 00:10 Сейчас в теме
(33)
А уж если и нужно в коде часто использовать данные этой константы, то пишем:
НашаПеременная = Константы.ЛюбаяКонстанта.Получить()
и дальше использ-уем НашаПеременная


А если нужно что-то вроде следующего решения?

Процедура ОбработатьЧтоТо(Ссылка)
  Если Константы.ЛюбаяКонстанта.Получить() Тогда
    //...
  КонецЕсли;
КонецПроцедуры

Процедура ОбработатьВсе()
  Для Каждого Ссылка Из ОбрабатываемыеСсылки Цикл
    ОбработатьЧтоТо(Ссылка);
  КонецЦикла:
КонецПроцедуры
Показать


Сохранение значения константы в переменной с дальнейшим распихиванием этой переменной в списки параметров всех вызываемых с ее использованием процедур и функций, как на мой взгляд - дурной тон.
Значительно элегантнее будет решение вида:

Процедура ОбработатьЧтоТо(Ссылка)
  Если ОбщийМодульПовтИсп.ЛюбаяКонстантаПолучить() Тогда
    //...
  КонецЕсли;
КонецПроцедуры

Процедура ОбработатьВсе()
  Для Каждого Ссылка Из ОбрабатываемыеСсылки Цикл
    ОбработатьЧтоТо(Ссылка);
  КонецЦикла:
КонецПроцедуры
Показать
38. Дмитрий Д (profiprog1c) 157 10.11.17 13:27 Сейчас в теме
(37) Вы давно 1С занимаетесь или недавно? Давайте уже включайте соображаловку. Учить азам я вас не буду. Константу 1 раз получаете в Процедуре ОбработатьВсе() до цикла, после передаете ее в Процедуру ОбработатьЧтоТо(Ссылка, НашаКонстанта) в цикле. Все просто.
Еще раз говорю, не нужно пытаться придумывать пользу от получения констант, займитесь программированием наконец.
40. Сергей Назаренко (Hobbit_Jedi) 10.11.17 16:56 Сейчас в теме
(38)
после передаете ее в Процедуру ОбработатьЧтоТо(Ссылка, НашаКонстанта) в цикле

Ага. Особенно если таких процедур штук двадцать... И они вызывают еще другие процедуры... А те в свою очередь еще процедуры... Везде добавляем аргумент со значением константы и передаем его?...
Как на мой взгляд, не самое лучшее архитектурное решение. Особенно, если добавленный аргумент в списке аргументов процедур как "не пришей кобыле хвост" смотрится (в том смысле, что не имеет отношения к решаемым процедурами задачам).
Но если Вы относитесь к программистам, не сильно заморачивающимся изяществом архитектуры, а стремящимся на скорую руку удовлетворить клиента (а заодно обеспечить себя в будущем большим количеством работы), тогда да - Ваше решение значительно эффективнее в достижении этих целей.
41. Дмитрий Д (profiprog1c) 157 10.11.17 18:19 Сейчас в теме
(40) Двадцать процедур, тридцать процедур. Давайте придумывайте сферического коня в вакууме. Вы написали конкретный код и я вам написал, как правильно программировать. Еще раз, у меня нет желания вас учить основам программирования. Продолжайте фантазировать на тему констант и двадцати тридцати процедур. Читать забавно
42. Сергей Назаренко (Hobbit_Jedi) 11.11.17 00:34 Сейчас в теме
(41)
Вы написали конкретный код и я вам написал, как правильно программировать.

Я привел ПРИМЕР кода. Естественно, максимально его упростив, т.к. 50 экранов текста никто читать не будет. А если у Вас недостаточно опыта, чтобы с помощью этого простого примера вспомнить реальный код соответствующего масштаба, то помалкивали бы тихонечко. И хотя бы типовые конфигурации полистали (как пример идеального кода они, конечно, не подойдут, а вот как пример сложной иерархии вызовов множества процедур - самое оно будет).
Успехов Вам в постижении программирования вообще и тонкостей 1С в частности!
43. Сергей Назаренко (Hobbit_Jedi) 11.11.17 00:38 Сейчас в теме
(41)
Ну и достану уже "козырную Мантану"....
Представьте себе, что Вам нужно читать значение константы в обработчике события, например ПриОтправкеДанныхПодчиненному, объекта плана обмена.
Интересно, где Вы предлагаете определить переменную? Где Вы предлагаете ее инициализировать прочитанным из константы значением? И самое главное - как Вы предлагаете передавать значение этой переменной в обработчик события, который при выгрузке данных на узел вызывается тысячи раз (по количеству выгружаемых объектов данных)?
Вряд ли Вы сможете ускорить процесс выгрузки не используя кэшируемые общие модули. :)
46. Дмитрий Д (profiprog1c) 157 13.11.17 13:39 Сейчас в теме
(43) "Козырная Монтана"??? Мне что-то смешно. Ладно. Вот "корызная Монтана". Я только что написал обработчик, который 50000 раз читает константу. Все это заняло 14 секунд. Так вот, если вы в реальном программировании используете такие циклы, на 50 тыс. раз, то эти 14 секунд ни на что влиять не будут. Так что советую изучить, что такое "производительность" и что реально требует оптимизации в реальном программировании, а не в Сферическом коне в вакууме, который вы мне тут упорно расписываете.
47. Сергей Назаренко (Hobbit_Jedi) 13.11.17 15:55 Сейчас в теме
(46) Иногда, 14 секунд - это очень долго.
К тому же помня, что "Сила мелочей - в их количестве"(С)Народ... очень часто приходится сталкиваться с вроде бы равномерно-тормозящим кодом (где оптимизировать вроде бы нечего), который путем "Сферических" оптимизаций можно ускорить раза в три.
Если код изначально писать оптимально (с точки зрения Сферического коня в вакууме), то зачастую, как Вы выразились "реальные оптимизации в реальном программировании" - не требуются вообще.
Хотя да - это мы с Вами уже в Холивар проваливаемся. У каждого свой путь на ниве программирования.
36. Яков Коган (Yashazz) 2149 08.09.17 12:30 Сейчас в теме
Да тема вообще практически не раскрыта. Ни срок жизни этого кэша, ни где он лежит (в сеансовых данных аль ишшо где), ни различия тонкого и толстого, ни различия повт.исп. на сервере и на клиенте... Можно было определить границу эффективности, за которой такое кэширование становится вредным и тормозным; можно было сравнить с параметром сеанса и его поведением; с поведением глобальных переменных модуля приложения, итд... Я уж не говорю о специфических вещах, как-то кэширование значения типа веб-прокси или ком-объект))

Ниочёмка с умным видом. Единственная заслуга статьи, за которую я плюсанул тоже - дискуссия пошла. Вот из дискуссии можно полезное почерпнуть.
Daynestro07; vano-ekt; spetzpozh; +3 Ответить
45. Роман Уничкин (unichkin) 699 11.11.17 12:21 Сейчас в теме
Некоторые константы удобнее кэшировать в параметры сеанса.. Вообще у меня в ПовтИсп есть такой метод:
Функция ЗначениеКонстанты(ИмяКонстанты, ПолучатьДанныеХранилища = Ложь) Экспорт		
	ЗначениеКонстанты = Константы[ИмяКонстанты].Получить();	
	Если ПолучатьДанныеХранилища И ТипЗнч(ЗначениеКонстанты) = Тип("ХранилищеЗначения") Тогда
		ЗначениеКонстанты  = ЗначениеКонстанты.Получить();		
	КонецЕсли; 
	
	Возврат ЗначениеКонстанты;
	
КонецФункции
Показать
48. Петр Лунегов (pvlunegov) 108 14.11.17 15:57 Сейчас в теме
Батенька, здесь в узких кругах народы привыкли к диссертациям в виде статей, а вы тут статейку написали, вот и ругаются, читать много букоф...

Мои мысли о применении фичи:
1. Мониторинг изменения данных в одной функции общего модуля с признаком повторные использование.
2. В функции получаем нужный список реквизитов нужного объекта метаданных. Храним значения в кешированной таблице.
3. Функцию получения реквизитов загоняем в цикл и гоняем туда сюда.
4. При изменении данных в существующих объектах, запускается отдельная процедура по проверке изменений.
5. Если изменения запрещены по определенному алгоритму - создаем электронное письмо администратору.

Как работает механизм:
1. Большие объемы изменения данных.
2. В момент изменения данных максимальная свобода и производительность системы без дополнительных проверок.
3. Все проверки в режиме оффлайн.
4. Проверка изменений осуществляется в оффлайн с помощью кеширования реквизитов и сравнения с существующими в базе.
5. Если реквизиты изменены не по правилам, то кеш сохраняется в файл на диске, админу 1с приходит письмо с описанием проблемы.
6. Админ разбирается в правомерности изменения данных.
7. Если изменение данных запрещено правилами, можно восстановить реквизиты из кеша, который сохранен на диск.

Плюсы:
1. Максимальная свобода изменения данных в базе.
2. Минимум проверок при записи в БД.
3. Высокая производительность.
4. Проверки делаются отдельно.

Минусы.
1. При большом количестве изменений кеши изменений будут очень большими, нужно место для хранения кешей таблиц.
49. zakiap (zakiap) 16.11.17 08:18 Сейчас в теме
А я использую так:
Функция Получить_ТаблицаЗначений(_имя) Экспорт
	Возврат Новый ТаблицаЗначений;
КонецФункции


далее

КешДокументов = КЭШ.Получить_ТаблицаЗначений("КешДокументов");
......
Оставьте свое сообщение