Заметил, что на ветке 8.3.27 (может такое встречалось и ранее, но на глаза не попадалось), конфигуратор очень безобразно обращается с памятью. Например делаешь тяжелую операцию (например загрузку изменений) - конфигуратор сожрал память. и он продолжает держать эту память, даже после завершения операции. Делаешь через некоторое время другую тяжелую операцию (например сравнить две конфигурации), конфигуратор тут же начинает захватывать новую память, не освободив перед этим старую, нахапанную в предыдущей операции, то есть он не использует что ранее зарезервировал, а берет новую, неиспользованную. И после нескольких таких тяжелых операций валится с воплем о нехватке памяти (так как сожрал всю доступную), хотя если между тяжелыми операциями выходить из конфигуратора и заходить обратно - никаких проблем с памятью не будет. Кто-то еще замечал подобное?

(0) Пока не успел установить, печально, что до сих пор платформу не могут доработать. Видимо, все силы на ИИ-сервисы и EDT уходит.

(0) А какова цель ветки?
Собрать сообщество страдающих?

(2) выяснить, вдруг проблема не в 1с а в моих кривых руках и надо просто что-то переустановить.

(3) воспроизводится и в 8.3.25

Думаете, я просто так 64 гига RAM на свой домашний 13900KF воткнул?

Упирался в память очень-очень редко, когда в 4 конфигураторах одновременно приходилось (2 ЕРПУХ + 2 ДО)

(1) и на зевающих котиков

(6) котики - это святое!
(4) я на 25-ой ветке не замечал, видимо если там и жрало память, не все так жестко было как в 27-ой. Или со временем умело освобождать.

с партнерского прекрасное
https://i.imgur.com/IDSXEIa.png

(8) Какая-то муйня из-под коня. В чем претензии автора этого опуса?

(9) ну там конфигуратор 50 гигов при глобальном поиске сожрал и помер

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

(10) Прикольно
Повторил влегкую на конфе ЕРП серверной PgSQL на платформе 8.3.24.1761

Тупо запустил в конфигураторе глобальный поиск "ном" поставив все галки

(12) а посвежее платформы не нашлось? щас в трендах 8.3.27

(12)+ Причем выглядит довольно смешно явно как некая бага
Сначала поиск идет нормально, память сильно не растет, всего 2 гига скушал
Затем дойдя до 38% поиск завис, Конфигуратор не отвечает и резко начало жрать память...

Уже 51 гиг скушало

(14)+ упс

попробуйте по Н поискать

(10) С макетами 1С плохо работает (ТабличныйДокумент).
Если строка большая в нем, то все виснет (хотя там текста в сумме на 1мб только). Я так пытался 10 значков в base64 хранить.

Проверил потребление ОЗУ только при сравнении с cf:
1. Сравнение ERP со старым релизом = 7105 МБ
2. Повторное сравнение с ней же = 7197 МБ
3. Сравнение с ERP УСО  = 7291 МБ
4. Сравнение с БП 3.0 = 7302 Мб
5. Сравнение ERP со старым релизом = 7294 МБ

1С 8.3.27.1688 + Win11 + 64Гб ОЗУ + AMD Ryzen 9 AM5 (не знаю имеет ли это значение)

Но с недавних версий 1С при проверке конфигурации (расширенный режим) в какие-то моменты подвисает вся операционка (Chrome, Telegram и тд) на секунд 10. Началось когда добавили ускорение проверки модулей.

(14) Утечка памяти видимо где-то на C++ на стороне 1С

(16) Это неважно
Явная ошибка/бага в платформе/конфигураторе

Суть что даже если хочу начать искать все буквы "а" - глобальный поиск должен или штатно отработать по любой конфе
Или остановиться с предупреждением, а не зависать с пожиранием памяти

(17)
>Утечка памяти видимо где-то на C++ на стороне 1С
т.к. 35% глобального поиска съедает только 2Гб ОЗУ сверху.

(16) лучше по пробелу, он чаще встречается чем все буквы.

(17) Если base64 то логично не в строке табличного макета хранить а отдельный макет выделять простой текст

(20) найти все ;

(21) Так и сделал, просто неожиданное поведение для меня.

(23) Скорее всего виснет парсер/отображение для ячеек
Возможно там память выделяется для колонки (или строки) из расчета максимального размера самой большой ячейки тупым умножением
Или нечто вроде

(12) Блин... эти ваши бесчеловечные эксперименты. Конфигуратор сожрал 158 ГБ оперативки (128 физической и 30 подкачки) и благополучно упал. 😥

(25) можно еще добавить поиск по файлам в глобальном поиске

(25) Ага теперь знаю способ отправить всех отдохнуть на общем RDP сервере для группы разрабов

(10) Ну просто не надо спрашивать у конфигуратора то, что встретится миллион раз. Не тупой же пользователь за управлением.

(28) А как теперь считать строки программного кода? Я раньше искал ";"

(28) Допустим надо везде в коде (куча доработок конфы) поменять префикс на другой
И?

(30) >допустим...

есть у вас файл текстовый на много-много гигабайт или xml

и в нем надо поискать и поменять

последовательное чтение придумали для такой ситуёвины, когда целиком в память не влезает. в 1С тоже заклинания завезли типа ЧтениеТекста()/ЗаписьТекста()

вариант действий? пофигуратор по глобальному поиску валится по нехватке памяти. ну всё, не шмогла. сдаёмси

(31) Ты предлагаешь вместо штатной возможности по рефакторингу в Конфигураторе изобретать нечто внешнее через выгрузку в файлы?
А нафуя тогда нужен Конфигуратор?

Имхо багу не исправляют чтобы заставить перейти на EDT

(32) я предлагаю искать пути решения (костыли и велосипеды), когда пофигуратор не шмог

"обновление через копию" не знаешь зачем в типовые завезли?

потому что "г@вно эта ваша 1С" :) может обновляться сутками, а работу работать когда?

(33) Плиз не надо искать оправдания ошибкам и багам

(34) ну я и не ищу оправдания

"страдаю/наслаждаюсь" за деньги как и все :)

вспомнилась длина тормозного пути одного неприятного бага в два года, когда при реструктуризации ИБ ПВХ очищались у объектов с возможностью измененения. хуле унывать? нашел как исправлять на тот момент

ERP после обновления на 2.5.12.265 пропали доп. реквизиты в отчетах

(31) тут ненормально то, что сама cfка весит пару гигов (при этом бОльшая часть из неё - бинарники всякие, в которых текст не должно искать), но при этом оно вот так вот жрет память.