Нас бухгалтера скоро убьют из-за этой Бухгалтерии 3.0..
Новая декларация на прибыль, в приложении 2 несколько десятков страниц, переход с одной страницы на другую занимает несколько минут в клиент-серверном режиме. В файловой копии на ssd-диске в монопольном режиме - 11 секунд!!
Разработчики при реализации декларации вообще о скорости не думали?
У нас в одной фирме более 200 страниц будет, работать реально невозможно!

(24)
>Разработчики при реализации декларации вообще о скорости не думали?

Думали. "Нам надо успеть как можно быстрее накодить декларацию до хх.хх.хххх"

В УПП моментально переходит в приложении 2.

У нас база на Oracle, администратор смотрит логи и хватается за голову - более 1500 операторов SQL в секунду!

(3)ну а кто вам виноват?что у вас все было хорошо в этой связке?

проверка при выгрузке выдает ошибку, что ИНН на какой-то странице 11 символов вместо 12, сколько часов потребуется чтобы найти ошибку?!

(3) это RLS в динамических списках такое делает :)
уберите просмотр "дерево"

а вообще по сабжу - почистите темпы 1с (в ап дата), ихмо дело в них а не в 1с...

(4) ага, блин, оракл виноват
если даже на быстром диске в файловой монопольной под полными правами все тормозит

(8) я этого не говорил.основная масса сидит на мелкософте и остальные имеют периодические проблемы.

(7) смотри (8)

(9) если я разверну на мелкософте стопудово скорость не увеличится

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

(10) а ты все-же посмотри темпы, тут такое дело, что 1с не всегда их чистит и когда в одной директории накапливается 50 000 файлов - все файловые операции становятся раком...

а отчеты именно с этими темпами и работают....

Вопрос в тему декларации, правда мы пытаемся ее сдать из БП 2.0, вопрос(вброс) следующий, при заполнении многостраничной формы отчета(у нас таких листов 19000) заполнение идет в начале бодренько, потом с наростанием количества листов, скорость добавления новых падает(до 6 секунд за одни лист), если я правльно понимаю что вся эта кипа табличных документов лежит в структуре(а стало-быть в памяти) при этом загрузка клиента 25% общей загрузки процесора, обмена с сервером нет все на клиенте, в диспечере потребление памяти тоже в разумных пределах 300-500 мб, вот вопрос вообщем то, как бы ускорить сий процесс ??? Сравнительный запуск клиента на серверной машние ощутимого прироста скорости не видно

(14) 19000 листов.. перед переходом на 3.0 потести декларацию..
если 1С не оптимизируют реглотчетность, тебе не поздоровится

(13) почистил кэш - не помогло ((

(16) чистил это?  C:\Users\ЮзерСлужбыСервера1с\AppData\Local\Temp

(17) нет, ступил

Специально не стали пробовать на 3.0, развернули 2.0 в толстом клиенте данные заплняем в декларацию для сдачи ))) но вопрос остается открытым, процесс пока идет и по приидкам когда он завершиться будут полные сутки на загрузку одной части декларации, приэтом она вполне нормально сохраняется и открывается(что меня удивило)

(17) там всего 32 файла, удаление не помогло
время перехода с одной страницы на другую с полными правами 5 минут 55 секунд при 73 страницах в приложении 2

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

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

(21) счаз на тестовой попробую
(22) вот-вот, я некорректный ИНН задолбался искать

а как мне искать? )))))

а отрадактировать = перезаполнить = сутки ожидания )))

писать обработку

ну как неприскорбно так и приходиться(мало того что полей в счетчике листо тока 3 а это 999 листо) листания с шагом <> 1 (произвольным) и прямой поиск

доступно и всерьез

(28) подскажите где реализовано лучше?

(29) не владею такой инфой.

(30) а зачем тогда ругаться

(31) а потому что ниче не оптимизировано.
не должен отчет так долго открываться, просто не должен!
уверен, если поискать, можно найти полно мест для оптимизации кода и ускорения формирования отчета.

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

(32) не все
может быть
как и в любой системе

(32) и кстати,что мешает написать разработчикам.уверен,что большинство забили

(34) мы собираемся

(31) > а зачем тогда ругаться

неконструктивная логика

(34) а смысл? я писал ро Рознице, были прям явные косяки.
так до сих и не исправили

(21) все тормоза в передаче с сервера на клиент:
есть клиентская процедура РазделыОтчетаПриАктивизацииСтроки(Элемент)
в ней 99% времени выполняется процедура ВывестиМакетСтраницыВТабличныйДокументНаСервере(Элемент.ТекущиеДанные.КолонкаРазделыОтчетаСокрНаим, Элемент.ТекущиеДанные.КолонкаНомерСтраницыРазделаОтчета, ЗаголовокРаздела);

если сделать замер в этой серверной процедуре, то все выполняется быстро - 99% времени идет возврат из этой процедуры на клиент

(38) попробуй запустить толстый клиент в режиме УФ...

у себя завтра посмотрю как и чего :)

(38) в любом случае к ораклу проблемма не имеет отношение :)

(39) та же мысль с толстым клиентом пришла

и еще, попробуй с чистого компа в полистать, там где не было никогда 1с...

возможно это проблеммы клиента...

толстый клиент не помог, сейчас попытаюсь чистый комп найти

(38) Гонять табличный док между клиентом и сервером - очень плохая идея. Надо бы переписать этот кусок так, чтобы все заполнение шло на клиенте.

(42) vde69, спасибо
дело действительно в клиенте
все работают через Citrix с терминального сервера
подключился с ноута напрямую - прирост в скорости перехода между страницами в 11 раз!!!
хоть и 20 секунд тоже не айс, но уже значительно лучше

(45) а теперь сделай с ноута замер производительности, посмотри на чем теперь слабое место....