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

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

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

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

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

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

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

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

(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)
Так ты и есть тот самый Маня или от него?