Оптимизация РассчитатьРегистрыНа #489981

Конфигурация что-то вроде ТиС для розничного магазина. Документ Реализация ТМЦ Продажи по принятой выручке жутко тормозит, подвисает. Сделал замер производительности 1.487592(21,82%) Занимает строка:        //*********************************************************** Гуглил, вопрос уже неоднократно задавался, но ответа так и не нашел. Вот думаю еденственный способ двигать точку актуальности. Если работаю с документом 15.06 то ТА ставить на 17.06 дабы ускорить процесс. Прав я или это не поможет? Может всетаки есть какое-нибудь решение?

Йося, вам таки лучше на сцене...

во-первых - фильтры устанавливать. во-вторых - не использовать временный расчёт во-третьих - использовать 1с++

+1 ускорить можно наложением фильтра

По фильтрам вроде нашел хорошую статейку, почитаю. А что можно сделать в режиме пользователя для ускорения процесса? Фильтры сможет поставить только программист.

Можно запретить пользовтелю вход в программу. Летать будет всё.

+1 И для начала выяснить какой рагистр тормозит при временном расчете. А не пачка ВремРегистры. Т.е. вставлять по одному регустру в эту пачку и делать замеры Иногда удается отделаться малой кровью - поставить галочку отбор движений у регистра. Впрочем у меня по умолчанию стоит у всех регистров

не считать регистры на. Для чего вообще ты их считаешь в заднем числе?

Незнаю! Тоесть предлагаете сделать:

без программиста - не работать задним числом

П-ц Пригласите спеца

"Дядя, ты дурак?"©

еще один момент - 20 процентов не так много, чтобы оптимизировать

Лан всем спасибо, пойду читать мат часть))

Достаточно. Тем более при массовых операциях...

согласись, что в 0 эти 20 процентов не уйдут? хорошо, если от этих 20 процентов сократишь хотя бы 50% - выигрыш в итоге 10% максимум - стоит оно того? - ХЗ

Если РассчитатьРегистрыНа занимает 20%, что же у них занимает 80% ?

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

а я его сразу жру. Выкини совсем эти расчеты, если не знаешь, зачем они нужны, и проверь. Если пользователи заметят разницу и начнут возмущаться - тогда уже чего-нить думать. А не начнут - так и не нужны они вовсе (вот такая умная мысль...блииин, зачем я вчера ...ну да ладно).

2 Выкинул, и в самом деле все летать стало. Только на пользователях такие эксперементы ставить не желательно. Это деньги и деньги не мои!

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

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

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

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

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

"ошибки связаные с партийностью"... Вообще-то, надо ругаться на "ошибки, связаные с полом", и - основное - ошибки в ДНК.

А вы, товарищ, оказывается, партЕйный?

есть и такое СоздатьОбъект("Регистры")

вроде уже со стажем, хотя 86-ой всё объясняет