Как там Гений говорит... Мой гений дарит вам...

Раньше я заводил тему про то что 1С жрет память и вообще тупит с таблицами - табличными частями, таблицами как реквизитами форм и так далее.

Сначала в рабой обработке с тысячами строк кода не мог врубится. Потом путем комментирования кода я выявил что гребет память. Оказалось что 1С тупо жрет память на создании и заполнении таблиц. Причем даже на пустых данных - просто заполняем пустые строки. Памяти отжирается дофига!

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

Тут же вспомнил про Тест Гилева. У меня комп в топе. Сам Тест гилева работает не понятно как. И короче я решил свою обработку тоже сделать тестом для всех. Пока простенько. Запускаете в своей 1С, и смотрите куак у вас создаются таблицы. Сколько времени и прочее. Все заносится в результаты. Есть два вида таблиц и так далее.

Обработка мне лично полезна будет для работы со своими клиентами. Я планирую еще туда добавить обмен результатами как у Гилева - информация о железе и прочее.

Обработка бесплатно. Скачать можно тут

https://subsystems.ru/news/generator-ogromnoy-tablitsy-test-skorosti-raboty-1s/

Напомню, ты настроил свой комп в 2 раза чем мог

в 2 раза хуже*

Если кто то хочет что то внести в обработку - ну как у Гилева. то давайте идеи. буду добавлять. Сделаем альтернативный тест 1С который будет понятен в том что он делает. Основная задача это работа оперативной памяти с таблицами и так далее.

Маня, ну вот куда ты со своими куцыми знаниями лезешь-то?
Людей посмешить?

(4) лезть туда куда я хочу это мое дело)

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

Диск в этом тесте совсем не участвует?
Не типичная для 1с нагрузка

(6) ты хочешь стать тестером платформы. При чем здесь тест Гилева и зачем это сообществу?

(7) в данном случае БД совсем не интересует. Важна работа 1С с данными на импорт, экспорт. Когда загоняются большие массивы данных в оперативку. Для разных задач.

(9) ну так потом же все это нужно будет записать? Иначе зачем загружать?

(9) зачем здесь 1с, если данные не читаются или пишутся в бд?

(10) изначально проблема возникла с тем что 1С жрет память. Как по твоему нормально что 1С на какой то голимой таблице в 500к - может 3 гига оперативки сожрать.

(11) 1С используют для разных задач. В том числе обработке данных из внешних источников

Сейчас очень много различных выгрузок, загрузок, обменов.
Многие работают и с API которые выдают данные.

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

Что будет когда 1С отожрет всю память и как будут выполнятся подобные операции дальше. Которые требуют оперативку.

(0) Как это поможет в реальной работе и оценки ?

(13) тест скорости или количества памяти?
Думаешь количество памяти будет както меняться?

(16) когда 1с отожрет всю память начнется подкачка

Всевозможные таблицы в 1С - наиболее используемый инструмент. Куда не плюнь то и дело сотнями создаются таблицы, табличные документы, табличные части. И прочее.

Расслабьтесь, Евгений, у вас не получится.

(21) на что спорим? У меня есть клиенская база, которой могу раздать обработку. И при условии отправки результатов увижу как у кого работает на их железе. Да и даже буду больше понимать на каком железе кто работает.
Какая скорость работы с этими данными и прочее.
Помогу клиентам задуматься о смене железа.

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

(22)
Настоящие герои всегда нужны.

Сейчас этот тест уже позволяет просто тупо в базе клиента указать количество строк - которое равно допустим самомому большому импорту в 1С. допустим даже прайс-листу поставщика.
И увидеть сколько времени просто тупо уйдет на создание промежуточного результата.

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

(22) (24) просто прогоняет задачу клиента(скорость выполнения которой его беспокоит) на эталонном железе и показываешь разницу.
Зачем нужен тест для особенных и нетипичных задач?

(27) ну блин у меня сотни юзеров именно с такими задачами) Мне с ними лично с каждым общаться?) Или проще дать обработку. Написать нажать кнопку. И увидеть где они там среди всех.

Я тупо встрою инструмент в свою подсистему. И они будут там играться. Все мы будем видеть чего у кого. Я к какждому не могу лесть смотреть чо у него там. И отладчиком хоть смотреть и рассказывать что у вас железо гамно.

(28) ля, ну сделай им кнопку "оценить железо" в маньякрпродукте. Обработку никто качать не будет

(30) да как не будет если о ней сообщить. Или встроить. Я сотнями продаю свои обработки.
Будет висеть в менюшке.

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

Вместо часа болтовни, одна кнопка и готово. с отправкой.

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

А тут мах и мат. Нажми кнопку - вот результат твой, вот десятков других. Все точка. Можно распечатать отнести отчет директору. А дальше его уже проблемы.

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

(33) запись в регистр замедлит обработку раз в 100

(33) ))) чувак я 10 лет занимаюсь с импортом в 1С.  У  кого то 500 товаров, а есть прайсы по 2 миллиона строк. У меня есть прайс и в 15 миллионов строк.
Ты мне рассказываешь) Не регистре сведений проблема.

Я как раз все знаю про импорт. И имею решения. И самое узкое место в этом даже не запись в регистр и не запросы к базе. А именно когда импортируются и экспортируются данные.

(34) у криворуких 100% замедлит

(35) Маня ты льстишь себе. Ты попал в струю, ты молодец, но криворукая поделка сабсистем, так и осталась поделкой.

(33) Вот тебе прим конкретный пример. в каждой типовой есть установка цен номенклатуры да и регистрация цен поставщика.

А теперь представь себе что импорт данных в 500 000 товаров. Это 5 установок цен по 100к. На один вид цены. А у многих 5 видов цен. Это уже будет 2.5 миллиона строк заполняемых в табличную часть документа. Еще не записанного в базе.

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

Пришло время битвы.

(39) не ежик, это с тобой можно пободаться, с Женей вряд ли. Он же "Гений 1С 2.0" тут без шансов.

(34) у тебя теория, у меня практика) У меня обработка делает все от чтения до записи в регистры и прочее.
Везде стоят логи, каждый шаг записан до секунды.
Если бы была проблема с регистрами)) то даже и темы этой не было бы)

Но я выявил в 1С именно то что как раз хуже чем регистры и все остальное вместе взятое. Даже запрос к базе с таблией в 500к и запросом к трем регистрам соединяющим с этой таблицей данные - работает в сто раз быстрее. Чем просто создание пустой таблицы с пустыми строками.

(41) вот уже здравые мысли пошли "работает в сто раз быстрее. Чем просто создание пустой таблицы" Все ж таки Евгений взял бы ты букварик по разработке СУБД на досуге и почитал бы. Таблицы значений неплохой инструмент для разового накопления и обработки небольшого объема данных. Если данных много и их нужно обрабатывать в разных направлениях заниматься этим через ТЗ плохо. Утечки памяти и прочее ...

(42) какая альтернатива?

Пока альтернативы нет, то нужно смотреть железо. Других вариантов нет. Это решает задачу для тех у кого этих данных дофига.
Собственно аксиома которую все знают.

А тест нужен больше для того чтобы где то там на том конце директору понесли отчет (так как на словах это болтовня), к нему нужно идти с бумажкой конкретной. Отчет и есть бумажка.
И тыкнули ему.
А дальше это все чисто его проблемы.

(0) держи в копилку
https://www.dropbox.com/s/qy2rs03rtjgrc43/ПроверкаПотребленияОЗУТабличныйДокумент.epf?dl=0

Есть другой еще вариант - ждать когда 1С что то сделает с этим.
Я не верю что в 1С разработчики платформы не могут справится с такой хренью как ТЗ.

Вот поэтому я и жду девятку))))))
Наплодили ТЗ, ТЧ, Табдоков.... в конфигураторе.... И все в разнобой. Везде свои ограничения. Проблемы, заботы.

Могли бы просто сделать  Таблица! наполнить ее всеми методами что только можно, включая функции эксель. Сделали бы чтобы работала со скоростью звука. и память не жрала. И было бы счастье.

(39) Сиквел "Поле Битвы:Земля" - "Поле битвы:Ростов", в главной роли - Маня на Логане

(47) Ни кто не устоит перед Высшим Благом!

(46) Зачем ждать, ты же Партнер! Пиши и требуй.
Проверил ради интереса (данные: 2 реквизита Строка(10) * 1М строк - чистых данных 40МБ)
Объект.ТЧ - 1,2 ГБ
ТЗ_РЕквизитФормы - 0,85 ГБ
ТЗ - 75Мб

На форму ничего не выведено. При очистке память не освобождается в обозримое время.

(50) вот и я о том же. жесть. вместо мегапрайс - гигабайты.

.....вместо мегабайт - гигабайты.

(51) Переходи на обычные формы, там таких проблем нет. ТЧ и ТЗ - меньше 100Мб.
Ну и собственно вывод: проблем не в ТЗ, а коллекциях форм УФ

Я б еще понял разница там ну 50 процентов между ТЗ без реквизита и ТЧ.

Но когда 10-20 раз... Это как 10-20 таких таблиц.

вывод: нужно полную тз держать в памяти, а на форму по странично выводить

Хихи) На ут10 у меня все есть на обычных формах) Все тоже самое)

(55) форма напричем вообще. можно даже убрать все из формы.

(57) в (50) другие показатели

Самый прикол что и ТабДок не подходит. Там тоже память жрет страшно. Процентов 60 забирает получение секции и вывод секции. По 30 процентов нагрузки. И памяти жрет все это.
Причем так док вообще без формы. в модуле выполняется.

(59) автовысоту отключаешь?

интересно, а массив структур или структура массивов больше ест?

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

И у программного ТЗ есть существенные недостатки, из за которых ну хоть тресни.

(62) я про это и написал: ручной постраничный вывод

И у таб доков есть недостатки. Короче одни сплошные недостатки. Еще и память все жрет)))

пиши свое на жс

(55) рукалицо

У меня там есть отчет на основании таблицы - как раз таб док. с кучей разных вариантов - что вытащить.
Так тупизна еще хуже)))) и все время на получение и вывод секций.

(66) сколько по времени в регистр будет записывать 1 кк строк?

(56) проверял на пустой базе ТЧ без вывода на форму - 75МБ

(69) вывод на форму у вообще отдельно замер поставил.
Заполнение ТЧ вообще идет на серваке. а не клиенте. даже в модуле обработки. а не формы. Поэтому все это вообще к форме не относится.

А замер на форму у меня отдельный стоит.

Смешались в кучу кони, люди...
Что за задачи такие, где могут конкурировать как инструменты ТЗ, РС и ТабДок?

(70) С ТЗ и <ТЧ в обычных формах> проблем нет.
Проблемы есть только в УФ и только с данными, которые могут мигрировать между К и С. И эти проблемы есть независимо от вывода этих реквизитов на форму. Т.е. хочешь ты или не хочешь в УФ эти данные будут сериализованы в какой-то мегатяжелый формат.

В обработку в сабже я сделал также  - там все происходит с ТЧ в модуле обьекта. Т.е к форме вообще не имеет отношения. Вывод на форму отдельная тема вообще. Это вообще к проблеме не относится.

(71) да элементано. Задач много. Ну давай пусть будет такая.

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

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

+(74) т.е. по факту мы не будем грузить. Но нам нужно все данные в 1С прогнать, соединить, получить и так далее.

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

(73) проверил в УФ с ТЧ копии экземпляра обработки. Проблемы нет, сожрало те же 75МБ
&НаСервере
Процедура ЗаполнитьТЧКопииОбработкиНаСервере()
    Обработка = РеквизитФормыВЗначение("Объект");
    ТЧ = Обработка.ТабличнаяЧасть1;
    Для инд = 1 По Объект.Строк Цикл
        ТЧ.Добавить()
    КонецЦикла;
КонецПроцедуры

(74)(75) Если критична производительность для подобных задач, то логично куда-нибудь в СУБД загнать.
Если же надо массовый продукт в 1С продавать, используй ТЗ - худо-бедно задача решается

Процедура ЗаполнитьТаблицуНаСервере() Экспорт
    
    НачалоЗагрузки = ТекущаяДата();

    Для Счетчик = 1 По КоличествоСтрок Цикл
        
        ТабличнаяЧасть.Добавить();
        
        //НоваяСтрока = ТабличнаяЧасть.Добавить();
        //НоваяСтрока.Колонка1 = 1000;
        //НоваяСтрока.Колонка2 = 2000;
        
    КонецЦикла;    
    
    КонецЗагрузки = ТекущаяДата();
    ВремяВыполнения = КонецЗагрузки - НачалоЗагрузки;
    
    СтрокаРезультата = РезультатыТестов.Добавить();
    СтрокаРезультата.ВариантТаблицы = "Табличная часть объекта";    
    СтрокаРезультата.КоличествоСтрок = КоличествоСтрок;
    СтрокаРезультата.ВремяВыполнения = ВремяВыполнения;
    
КонецПроцедуры


900 мегабайт плюс

(78)
где выполняется код?
ТабличнаяЧасть - это что?
Структура ТабличнаяЧасть?
КоличествоСтрок?

+(79) как вызывается этот код?

(77) ну скажем так. Особо это и не проблема. Так как таких клиентов с 2 млн нет. И даже 100к редко у кого))
Большая часть вообще 10к. И вообще все летает)))

Тех клиентов у кого 500к и 2 миллиона - я им сразу отсекаю что 1С не для этого. И говорю что не подойдет.

Но сейчас вся эта тема мной разожглась чисто из научного интереса)) Так как хотелось бы чтобы 1С могла тянуть и такое. Клиенты с такими объемами денег не жалеют. У кого столько товаров - тому 200к рублей заплатить вообще не проблема за решение. А мне они бы как то были не лишними)) даже если 2 таких клиента будет в год)))

Поэтому время потерять на изучение мне не лень. К тому же интересная тема.

Обработка для теста в любом случае сгодится даже для тех у кого 20к строк. Так как бывают и у кого 20к товаров но 100 поставщиков. Они хотят тоже все сравнивать и крутить вертеть. У многих выгрузки всякие.

Короче работа с обьемами данных дофига у кого. Смотреть что за железо тоже нужно. И рекомендовать сменить сервер. и прочее. тут тоже может какую то копейку можно заработать за рекомендации.

(80) ты бы уже давно скачал бы файл по ссылке. там весь код. и ТЧ и ТЗ.

(68) у меня прайсы поставщиков (148 прайсов) в 10 потоков пишутся в РС около минуты, получается порядка 15 млн строк. Потом их анализирует отдельный процесс и выдает человеку решение о повышении снижении продажных цен по остаткам. Потом этот человек работает с этими 15 млн строк по закупкам. Когда человек формирует прайс предприятия к обеду где то - РС уничтожается. Таблица РС порядка 18 гиг.
Ты написал - хранить в памяти ТЗ и выдавать порциями. Представляешь себе в памяти 15 млн строк? Зачем выдавать порциями, если есть стандартный механизм "динамический список" и "select top 33"
Кстати товарищи смотрели манину поделку в свое время, но она на их объемах и под их задачи не заработала.

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

(82) ля, какая разница где и как ты её заполняешь, если в итоге ты её пихаешь в реквизит формы со всеми вытекащими

    ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
    ОбработкаОбъект.ЗаполнитьТаблицуНаСервере();
    ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");//проблема здесь!

(85) да блин епт. Память срется не от формы. А от заполнения ТЧ. создания строк. Сама ТЧ память. А не наличие ее на форме.

(85) нет пробюлемы с формой. то что ты показываешь это уже после того как память засралась.
Да, передача на форму - занимает время. Секунд 10-20. Но я их не засекаю. Меня волнует не отображение. А то что в памяти 2-3 гига отожралось.

(86) Именно от сериализации в данные формы. Происходит это даже без передачи на клиент

(87) посмотри (76), там память не жрется. И в обычных формах не жрется

Сам факт заполнения строк - жрет память. Выкинь форму из головы.

(89) ок. отредактируй обработку мою как считаешь нужным и вышли мне в скайп Skype: shekineugeniy
я ее запущу скажу что у меня.

(90)(91)  закоменть одну строку и проверь. Жрет 1,5X, а в данных формы 20-30x

&НаСервере
Процедура ЗаполнитьТаблицуНаСервере2()  
    
    ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
    ОбработкаОбъект.ЗаполнитьТаблицуНаСервере();
    //ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

КонецПроцедуры

&НаСервере
Процедура ЗаполнитьТаблицуНаСервере()  
    
    НачалоЗагрузки = ТекущаяДата();

    Для Счетчик = 1 По Объект.КоличествоСтрок Цикл
                
        НоваяСтрока = Объект.ТабличнаяЧасть.Добавить();
        НоваяСтрока.Колонка1 = 1000;
        НоваяСтрока.Колонка2 = 2000;
        
    КонецЦикла;    
    
    КонецЗагрузки = ТекущаяДата();
    ВремяВыполнения = КонецЗагрузки - НачалоЗагрузки;
    
    СтрокаРезультата = Объект.РезультатыТестов.Добавить();  
    СтрокаРезультата.Дата = ТекущаяДата();
    СтрокаРезультата.ВариантТаблицы = "Табличная часть объекта";    
    СтрокаРезультата.КоличествоСтрок = Объект.КоличествоСтрок;
    СтрокаРезультата.ВремяВыполнения = ВремяВыполнения;

КонецПроцедуры


вот уже два варианта сделал

(85) че, рилли Анжинер не понимает, что тут сериализация происходит, которая и кушает все?

Выше уже два варианта. Да закомментировал строку.

Память кажись не отжиралась. даже комп не шумел.

Да ты прав. Вывод на форму жрет всю память.

(83) если 15 млн строк поместить в CSV файл, то я тебе за одну минуту без регистров) могу его бойти и наценки сделать, проценки, даже фильтры и сгенерировать новый файл с новыми данными.
1С творит чудеса с CSV.

Я наделал кучу обработок с CSV. которые могуи слепливать кучу файлов, и менять данные и все прочее.
Если бы все присылали все в CSV - то вообще бы сказка была.

(97) так делай csv, в чем проблема то?

Я даже в загрузке сделал конвертацию. Присылают эксели кривые косые какие угодно. Обработка одной из функций держит после всех настроек и синхронизации. Не писать в 1С и выгрузить все в CSV (причем все получаются в одном формате). А другая обработка может скопом считать все CSV и чо угодно там навертеть.

(98) да с этим проблем нет)) это нужно только редким клиентам) остальные все все равно в 1С хотят тянуть)) Да и с ними проблем нет. Там все до 20к строк...

Я ж выше написал, что тема с объемами интересна для захвата тоже единиц клиентов. А также с научной точки зрения.

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

Я не правильно оценил строку кода.

Бред конечно... но пипец. Это явный глюк платформы.

1-2 гига чтобы показать таблицу.....

Походу на форме хранится хмл сериализация не пожатая

Походу УФ авно. ну как так.

Самому рисовать таблицы.
Ну или в рс пихать в многопотоке

(98) "если 15 млн строк поместить в CSV файл, то я тебе за одну минуту" "1С творит чудеса с CSV" :))
какой нибудь C# или паскаль перелопатит твои 15 млн за пару секунд

(100) отож, неча на 1с пенять. Но ошибки бывают, они приносят нам новые знания

(102) нахрена тебе смотреть на таблицу в 3 гига. ты её лет 10 будешь листать

Маня осваивает УФ и нормальную клиент-серверную систему.

(108) причем тут гиги) Там строки. 20-50-100-200 тысяч строк. Пофиг. Мне вообще неизвестно у кого сколько конкретно строк. Это всего инструмент.

Есть у кого 500 строк, а кто то с 2 млн приходит. Листать и не нужно. Но в ТЧ можно играться с этим. Сортировки, отборы. и прочее. Считай таблица данных, с которой можно вертеться.

Пока что известно то что 500к (и даже 1 млн) это 2-4 гига памяти на вывод. и где то секунд 20 на показ.

Это мелочи. Что сейчас такое 2 гига - открытый браузер. Другая проблема что не хочется чтобы 1С стока драла.

У меня если чо вообще как бы эта обработка для регл заданий)) Там если заданиями все - то и вывода нет никакого) Все также в РС льется если стоит галка.

Вот только что запустил тот же файл в 400к строк . 1 минута полный цикл. Без изменений памяти.

Да черт. Наифга. Жрется память. Переоткрыл, запустил тоже самое. Фоном. Без какой либо формы. Вообще все целиком исключительно в модуле. И 3 гига нет.

(110) ну добавляй в справочник и играйся. в 1с не обязаны твои извращения поддерживать

Короче пока нфиг)) выходной.
2 минуты чтения и загрузки всего в регистр фоном. без всякого показа. и заливки 400 тысяч овна.
5 гиг оперативки (семечки).

Пусть кому надо серваки нормальные покупают. А не работают на овке 12 года. Я вон у Гилева увидел тех у кого там 10-20 показатель. Почти вся моя клиентура - с ксеонами E5

А как же тест?

Тест остается и будет развиваться! Я в нем учту создание таблиц на сервере, клиенте. Отдельно показ в форме.
Тем более он мне очень нужен для моих задач и клиентов.

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

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

Ни кто не устоит перед Высшим Благом!

Думаю встрою себе в подсистему сразу. С моими регистрами.
А также возможно создам расширение на Управляемых формах или просто отдельную конфигу.

У Гилева там готовый инструмент, он прикольный. базару нет. люди вложились трудозатратами. Но мне мой будет более понятный, потому что я делаю решения. И мне будет отлично запускать тест решения у клиентов на одном и тот же объеме - например 100-500к строк. Чтобы возможно было сравнить между всеми на одном обьеме результаты.

Гилев у себя закрыл как он получает системную иформацию различную. а в 1С скромный инструмент получения инфо о памяти и так далее.

Вот мой гений дарит вам... Нашел вариант как уменьшить память.

ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
    ОбработкаОбъект.ЗаполнитьТаблицуНаСервере(Объект.ТабличнаяЧасть);
    //ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");


Не используем ЗначениеВРеквизитФормы вообще.

Но если в параметр процедуры мы передаем Объект.ТабличнаяЧасть то память жрется но значительно меньше. А также отображение гораздо быстрее.
Короче 1С страшно тупит когда мы весь объект пытаемся снова в форму впихнуть.

Там видимо огромная утечка памяти даже не при какой то таблице. А вообще по всему обьекту.

Короче вот это ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");  - это полный пистец.

Я конечно не знаю товарищи. Но по мне это просто дикий песец. И дикий он потому что 2022 год. Сколько там уже этим УФ и восьмерке лет.

И речь то идет по сути об одной строке кода - методе. Я считаю это величайшим багом в 1С, который вот прям на глазах есть. И всем начхать)))

Это жесть конечно же. Всего один метод фигачит утечку памяти и затупливает 1С так что i9 у меня вентиляторы запускает как будто плюс 70 жара.

ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

Это не утечка, просто так много доп данных приходится хранить

А если только тч назад возращать, а не всю обработку?

(124) Ты еще бесконечный цикл запусти и сиди, убивайся, что проц греется. Делает глупости, а виновата 1с.

(126) а и сделал ТЧ. параметром. Утечка ушла.

Проблема будет только если слишком много каких то вещей понадобится с сервера. Но думаю не много.

Баг 1С на лицо. И я считаю недопустимо чтобы такой баг был.

(127) виновата еще как. Ее же код - метод)) А не мой. Значит не я говнокодер)) Уже гора с плеч.

ЗначениеВРеквизитФормы - убивает память в хлам. Факт.

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

(129) ну не используй ЗначениеВРеквизитФормы, есть же другие методы, алло

(131) это очень жестко. Выдернуть одну только таблицу с сервака и вернуть ее на форму это очень тяжело. Особенно если в модуле по ней дофига чего процедур и прочего

Ее практьически одну невозможно вернуть. Это по всему коду вообще везде параметр надо и передавать ее. по всем процедурам и функциям.
Уже в модуле не получится обращаться к ней как просто к реквизиту обьекта. Иначе на самом серваке может быть все сработает с ней. А вот на форму чисто ее никак.

Поэтому придется прям везде в параметры пихать

(133) а в чем проблема? Можешь ее сформулировать? Зачем тебе таблицу с сервака на форму передавать? тем более большую? зачем тебе вообще программно с формами объектов с большой табличной частью работатЬ? обычно больше 99к строк не делаю в табличной части, надо бить такие большие документы.

(134) да у тебя и 99 и 20к. будут вызывать утечку. ты пойми что глюк 1С делает утечку памяти по этому методу в 10-20 раз.
Просто я на тесте 500к терял 3 гига. Ну а ты будешь терять 200-300-500 мегабайт Это тоже как то не очень приятно. Когда просто так.

(135) Да угомонись ты со своей утечкой. Ты просто понапрограммировал, по незнанию, какой то херни. А утечки нету.

(134) чувак - люди бывают работают с каталогом в 100к номенклатуры. У некоторых есть и миллионы.
Да они хотят получать таблицы. Мало ли - что угодно могут хотеть. Любые таблицы, данные. Какая разница.

Они что виноваты чт оу кого то 2000 товаров, а у них каталоги по 500к. Или по твоему у кого много номенклатуры - пшел нафиг.

(137) какого рода таблицы? если речь о табличных частях документов, то нет, там больше 99 не вмещается. Если речь о регистрах и справочниках, там используются динамические списки, а не табличные части. Алле.

Тем более удивительно что 1С себя позиционирует уже как мега супер платформа. тысячи юзеров. Производства целые. Кластеры.

А тут просто фиговая задача, а утечка выше крыши)) Если про такое узнают какие нибудь другие кодеры, они ржать будут. Что 1С на таблицах и формах грызет.

(139) анженер, в чем задача-то. поясни. подсказываю - ты ТЗ можешь сохранить на сервере ПоместитьВоВременноеХранилище

(138) кто тебе сказал что не вмещается))0 вмещается сколько хочешь. это номера строк не будут больше 99 999. Но фактически может быть любой. Просто все строки свыше будут 99 999 иметь номер.

Кстати это тоже бесит. Мегапратформа не может назначать больше 99 999 строк)))

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

(141) больше 99.999 строк в ТЧ - это проблема архитектора. Не стоит так проектировать данные.

(140) вообще не вариант. еще хуже. это придется помещать, вытаскитвать, снова помещать, снова вытаскивать. это будет ад адский. Для разовой ситуации еще можно. Если какие то активности с ней то уже нет.

У меня там целый набор процедур с таблицей. десятки команд. и нажатиями форме, и просто отметкой галочек - которые потом в регламенте будут в модуле выполнять десятки процедур.

ты мне предлагаешь веще из хранилища дергать таблицу в 500к строк))) нет спасибо.

(143) это проблема 1С. таких ограничений нет ни в одной нормальной программе. Мало того это просто смешное количество.

Гений еще раз. Ты совсем не понимаешь что я тебе говорю. Есть фирмы с 2000 товаров и там бухи в толонок плюют - пять строчек руками в накладные набивают 10 штук в день.

А есть компани где десятки сотни тысяч товаров. Они их прогоняют туда сюда, смотрят, да, какие то действия делают с этими данными. и крутят вертят. Для этого 1С выбрали.

(144) погоди. о какой ситуации идеть речь? ты хочешь использовать типовой справочник/документ, у которого есть типовая форма от 1С, но с большим количеством строк или че?
(145) ты занимаешься нытьем, давай решать проблему

В автозапчастях чуть ли не постоянная задача - проценка. А там прайс листы в миллионы строк.
Нужно сопоставить, сравнить, проценить. Проценка это еще различные условия.

И да прикол в чем - сделать это все не имея даже номенклатуры в базе. Т.е. нужно все подгрузить виртуально. Без записи в базу. Что то синхронизировать то что в базе есть, остальное - предоставить выбор. Типа кликнет на 1-2-5 производителей которые попались в загрузках и создать.
Еще просмотреть что за список будет.

Вагон и тележка возможных действий юзера.

(147) да я уже решил. Я выше написал несколько раз. Отлично работает если убрать кривой метод и передавать таблицу в параметр. правда придется везде ее передавать параметром по всем процедурам модуля. Уже сделал.

Но надо добавиться исправления бага от 1С.

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

(151) это не косяк и не утечка. Это особенность сериализации данных формы, не более того

(152) давайте не гадать. фактически - утечка памяти.

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

(153) ты не понимаешь что такое утечка. Это не утечка

(148) и ты хочешь все это грузить в память? окстись... разбивай прайс на пакеты и грузи их частями. или юзаю не-1с-базу данных

(153) нет, тут с тобой никто не согласится

(148) ну или грузи все в таблицу на сервере, а на форму передавай частями. Отборы сам напиши

(144) в хранилище достаточно быстро кладется.
А похорошему нужна отдельная субд и балк инсерт туда

(159) какой нибудь my-sql вполне может подойти. Там для старта сервера 1 exe шника достаточно

на c# excel в csv и в базу - все будет очень быстро

(160) не в коня корм. он кроме 1с ничего не понимает.

(156) а в чем проблема с памятью? мы как мидим что 1С легко 500к делает таблицы. 4 секунды. без проблем. всего пара десятков мегабайт.

Мало тебе я больше скажу - о чем не говорил. помимо ТЧ, у меня уже до этог ов 1С в памяти висят ТЗ в которую считаны все эти 500к строк. Но там еще неизвестно что есть что.

Из той ТЗ я делаю другую ТЗ - где уже распознано что есть что. И тоже ноу проблем))) И фоном даже все работает на ура.

Еще раз - проблема с формой))) Забудь про то что там миллионы строк и зачем они) Для оперативки это фигня!!! Как и для подобных задач.

Глюк в 1С в конкретном методе. Один единственный метод. И это глюк платформы.

(163) напиши в 1с может поправят

(163) как увидеть твою утечку? я скачал твою обработку, нажал на кнопку на обоих вкладках. сожрало гиг. что не так?

(165) а не должно жрать гиг))) кстати обработку я допилю. есть вариант без утечки.

(166) откуда тебе знать то сколько должно быть? :)

(167) там где-то выше опыты проводили. в 10 раз меньше

(160) не катит. Почему это нужно в 1С даже объяснять лень. Это не я кроме 1С ничего не знаю) Это вы не знаете для чего нужна 1С)

(160) пусть анженер напишет Базуху, ггг
(163) там сериализация идет через XML, поэтому это не глюк. Никто не планировал гонять с клиента на сервер такие объемы. Окстись, еще раз тебе говорю.
(164) Не смогут, такое поведение не задумано.

(168) ну если писать херню, то и будет память жрать. всё предсказуемо. какие претензии то к 1с.

(167) разные тесты показывают что в 10-20 раз меньше.

(171) т.е. хочешь сказать что стандартный метод встроенного языка 1С - это херня. И его писать не нужно. В данном конкретном случае это верно.

По сериализации насколько я почитал материалы. Все пишут что она в основном для сохранения, восстановления настроек.

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

Сделал поиск по УТ11 насчет ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

Нашел пару десятков использований.

Типовые обработки -
ЗагрузкаЦЕнПоставщикаИзВнешнихФайлов - бугагага.....
КлиентБанк - выгрузка.
СопоставлениеОбъектовБаз
ИсправленияОстатковОрганизаций
УДАЛЕНИЕ  НЕИСПОЛЬЗУЕМЫХ ОБЕЪКТОВ
И внимание
УниверсальныйОбменданнымиXML

ну и еще десятки других.

(174) чтоб по сети передать данные их нужно сериализовать

+(176) это все делает платформа. у нас к ней доступа нет. мы этим не управляем. нам дают методы конфигуратора.

Если эти методы - вызывают потерю памяти и разгон процессора, то .... ну а дальше слов нет)))

(177) Тормозят УФ, ничего не поделаешь

Вот ПИСЕЦ

ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
ОбработкаОбъект.ЗаполнитьТаблицуНаСервере();
ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

ВОТ ТОЖЕ САМОЕ но нормально.

ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
ОбработкаОбъект.ЗаполнитьТаблицуНаСервере(Объект.ТабличнаяЧасть);
//ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

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

(179) У меня 1 гиг после нажатия двух кнопок. 2 гига нету.
Кто тебе сказал, что это потеря памяти? Просто выделяет заранее побольше. Чтобы два раза в магазин не бегать.

А вабще это ООП и XML. Два тормоза перестройки. Без них всё летало.

Блин какой то косяк есть....

ОбработкаОбъект.ЗаполнитьТаблицуНаСервере(Объект.ТабличнаяЧасть);

если я начинаю передавать параметром ТЧ в модуль в процедуру.

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

То переданная параметром ТЧ - не заполняется тем что делают другие процедуры. Те модуль обработки не видит эту ТЧ обьекта переданную как параметр. А видимо видит другую ТЧ.

Короче у меня уже баржак в голове. Теперь модуль хрен знает как работает. Тогда придется везде во всех процедурах передавать параметром ТЧ переданную из формы. А внутреннюю (данные) типа пустые.

Епт. Нет в жизни счастья.

Уета полная получается. разные ТЧ. Одна из формы параметром идет, другая которая обьект на сервере пустая. Кучи процедур. Все переписывать надо, только ради того чтобы на форме отрисовать без зависона. Бред.

Пока притоплю ветку. Автор в раздумьях.

Короче полная уета. Я не знаю что виновато.

Я поставил три замера (просто сообщениями). И вот что вышло


&НаСервере
Процедура ЗаполнитьТаблицуНаСервере()  
    
    НачалоЗагрузки = ТекущаяДата();

    ОбработкаОбъект = РеквизитФормыВЗначение("Объект");        
    ОбработкаОбъект.ЗаполнитьТаблицуНаСервере();    
    КонецЗагрузки = ТекущаяДата();
    ВремяВыполнения = КонецЗагрузки - НачалоЗагрузки;  
    Сообщить(ВремяВыполнения);

    ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");      
        
    КонецЗагрузки = ТекущаяДата();
    ВремяВыполнения = КонецЗагрузки - НачалоЗагрузки;  
    Сообщить(ВремяВыполнения);

    
КонецПроцедуры


&НаКлиенте
Процедура ЗаполнитьТаблицу(Команда)
    
    НачалоЗагрузки = ТекущаяДата();

    ЗаполнитьТаблицуНаСервере();  
    
    КонецЗагрузки = ТекущаяДата();
    ВремяВыполнения = КонецЗагрузки - НачалоЗагрузки;  
    Сообщить(ВремяВыполнения);

    
КонецПроцедуры



Результаты

Заполнение таблицы в модуле обьекта - 4 секунда работы.

ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект"); - 9 секунда работы

Завершение серверной процедуры формы и возврат в клиентскую - 27 секунда работы.

  
Наибольшее количество времени занял просто выход из серверной процедуры в клиент. Так как серверная выполнялась с контекстом и меняли мы данные обьекта, по сути сжирает все тупо изменение обьекта.

И там начхать. хоть параметром, хоть без параметра. хоть с использованием ЗначениеВРеквизитФормы хоть без него. Все равно жрет память.


ОбработкаОбъект = РеквизитФормыВЗначение("Объект");        
ОбработкаОбъект.ЗаполнитьТаблицуНаСервере(Объект.ТабличнаяЧасть);    
//ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");      


Если сделать так. то будет 4 секунды заполнения. и 22 секунды общего выполнения до выхода в клиенскую команду.

В итоге пофиг ВСЕ. экономия есть 5 секунд.
Но это ничто по сравнению с тем что все сжирается фактически даже не кодом, а просто тем что мы выполняли серверную процедуру с контекстом и меняли обьект. Программно это не управляется никак. Никакой код не сжирает память.
По сути это обыкновенное поведение 1С между клиент-серверными процедурами какого либо объекта.

По факту это значит что что при работе с любым обьектом в 1С (например НОВЫЙ документ с табличной частью). и допустим кнопкой заполнить (да просто заполнить по самые 99 999 строк). То получим сжирание памяти и тормоза.
Сами ТЧ будут заполняться может быть быстро, а вот показ на форме при открытом документе - в 4-5 раз тормознее. Еще при этом и память засирается.

ВЫВОД ТУТ ТОЛЬКО ОДИН - 1С не умеет работать с большим количеством данных в формах объектов которые содержат какие либо таблицы заполненные данными.

С другой стороны 500к строк данных - не так и мало. 20 секунд подождать скорее всего норма. Я думаю даже штатный отчет в 1С любой на 500к строк будет еще дольше крутиться.
А тут всего 20 секунд.
Другое дело что памяти 2-3 гига на это явно ну перебор. С учетом того что если на форму не выводим то вообще нет потери. Хотя таблица в оперативке уже сидит.

Рома ты сбил меня с толку своими показателями памяти. А потом я увидел что у тебя всего 2 колонки. А я их сделал 10.
Количество колонок таблицы имеет значение. Память жрет пропорционально количеству реквизитов и их типов.
Даже не смотря на то что мы не заполняем.

Неугомонный. Тебе же объяснили уже 100 раз. Это сериализация в xml столько памяти жрет. Наверняка на клиенте хранится вся форма в xml тексте, да еще и в DOM. УФ не предназначены для таких извращений. Успокойся.

(190) да вот ему и объясняют, а он не догоняет.

Специально для автора.
Записал таблицу значений в 500000 строк в файл xml. В С# загрузил в DOM. Сожрало 1.5 гига.

FreePascal вообще сожрал 3 гига. Так что в 1с еще более менее прилично всё :)

(193) freepascal разве не юзает типовой ms  xml dom ?

(190) по сути ты говоришь - Утверждение 1С не предназначена для таких задач....

Т.е. если у компании 200к товаров то 1С для всех не предназначена. Никакой крупняк типа Озона работать на ней не должен! Как ивообще все у кого большие каталоги.
Только те у кого 10 тысяч товаров.
Так и запишем.

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

1С ручная программа для ввода. Если ты работаешь на клиенте - то обязан на клиенте ничего не делать на сервере. Твое жалкое существование - это максимум отчетики крутить. И документики по 5 строк набивать.

Вместо 1 юзера должно работать 500. Все должны только руками работать.

(194) Нафига ему этот типовой. FreePascal же супероссплатформенный. У него всё своё. Да и своего несколько библиотек. Я Laz2_dom пробовал.

(195) тебе уже писали, что нужно это делать по другому, а не рыдать и молиться.

(194) Там в еще косяк есть, List так реализован, что при расширении, удваивает количество памяти для следующей вставки объектов. Т.е. могло получиться так, что реальных объектов в списке 1001, а памяти выделено на 2000. Я когда то даже исправлял эту хрень, делал чтобы выделялось равными порциями а не (размер  списка * 2), когда надо было большие файлы грузить в DOM.

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

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

(201) не прошло и 25 лет, как были постигнуты основы работы с базами данных...

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

(203) через 10 лет. ни юзеров ни программистов не будет. Никто смотреть ничего вообще не будет. А программисты нафиг не нужны будут.
И это произойдет по двум причинам

1) это так сделают
2) ядерные войны снесут все нафиг

(204) ты 10 лет тоже самое говорил

(204) Довожу инфу (из проверенных источников):

1. Программисты будут нужны всегда.
2. Ядерной войны не будет.

-(0) у вашего теста нет четкой цели, есть только "что то потестировать"
сначала должна четко сформулированная задача с условиями и ограничениями, потом всё остальное

(201) А говорят, что браузерная версия себя по другому ведёт, чем тонкий клиент, на больших таблицах. Правда или нет?

(0)
Так ты и есть тот самый Маня или от него?