Добрый день.
Пути оптимизации кода и повышения производительности.

Рекомендации.
1. Формировать список документов для проверки контрольных условий и изменений не через выборку , а через запрос . Алгоритм использования выборки не оптимальный. По сути сначала идет выборка всех документов всех видов за дату по определенному контрагенту, а только потом отсечение всех документов с видом отличным от Счет.
Предположу что объем такой выборки очень значителен.

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

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

2. Упростить первое условие из сочетания различных условий до элементарных, поскольку конструкция требует вычисления, в дополнение код станет более читабельный за счет конструкции отсечения граничных условий.
Если (ДокСчет.ФизАдрес=ФизАдрес) И (ДокСчет.Маршрут<>Маршрут) И (ДокСчет<>ТекущийДокумент()) Тогда

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

Пример построение условий:
Если ДокСчет=ТекущийДокумент() Тогда Продолжить;КонецЕсли;
Если ДокСчет.Маршрут=Маршрут Тогда Продолжить;КонецЕсли;
Если ДокСчет.ФизАдрес<>ФизАдрес Тогда Продолжить;КонецЕсли;

В случае если переделаете код на работу через запрос то условия могут успользоваться к полям строк таблицы значение либо сразу применены в тексте запроса

3. Перед началом цикла в котором используется Записать() использовать директиву
НачатьТранзакцию()
после завершения цикла -
ЗавершитьТранзакцию(). (кажись так года три не программировал на 1С)

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


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

Удачи.

OlegKorПонимаешь? Суть как-раз в том, что "каждый байт на счету" в таблице RG_1270 .... 12 миллионов записей. В других таблицах ситуация похожа.
Судя по данной фразе проблема в ошибках при проектировании структуры и алгоритмов проведения по регистрам.
В первую очередь оптимизация структуры и основных алгоритмов, во вторую оптимизация кода.
Ну и соответствующий бюджет под это дело - то что "съекономили" на этапе формулирования требований, постановки задачи, проектирования и разработки - "вынь да полож" для приведения системы к насущным бизнес-требованиям.
Хотя, если принимается решение что пол дня половина пользователей, пол дня другая, серьезные отчеты запускаем вечерами или по выходным то бизнес-заказчика текущая производительность и ограничения работы системы устраивает.
Так что Олег, Вы для себя конечно разберитесь в чем проблема и уточните определенные моменты, это очень похвально что вы проявляете в этом вопросе настойчивость, дополнительный опыт никогда не помешает, но вот кидаться на амбразуру и вызывать огонь на себя это на данном этапе лишнее.
Рекомендую по результатам ваших исследований подготовить руководству аналитическую записку с прогнозами в отношении необходимости бесперспективного наращивания мощностей железа при условии наличия "белых пятен" в проектировании и производительности информационной системы.

P.S. Вот из-за таких подходов к проектированию систем и "програмистов 1С" падает интерес, а зачастую и образуется негатив профессионального сообщества к самой платформе.

OlegKor авторПри этом нового функционала они не получат, а получат всё "быстрее"
Да и не надо НОВОГО, пусть хоть это заработает по-человечески.
Увы, понятия - "по человечески" в бизнес-среде не существует.
Если надо то 20 теток посадят со счетами за "три копейки" делать бессмысленную тупую работу.... "не по человечески"? - зато выгоднее для бизнеса.

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