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

По непонятной причине в макет (да и в mxl) дописывается совершенно абсурдный кусок типа

{#base64:77u/MiwxLDM4MWVkNjI0LTkyMTctNGU2My04NWRiLWM0YzNjYjg3ZGFhZSwNCnsN

Cns5LA0KeyJQYXR0ZXJuIiwNCnsiRCIsIkQifQ0KfSwNCnsNCnsNCnsxMCwxLA0K

ezMsNCwNCnswfQ0KfSwNCnszLDQsDQp7MH0NCn0sDQp7NiwzLDAsMX0sMCwNCnsz

LDMsDQp7LTIyfQ0KfSwNCnszLDQsDQp7MH0NCn0sDQp7Myw0LA0KezB9DQp9LA0K

ezMsMywNCnstN30NCn0sDQp7MywzLA0Key0yMX0NCn0sDQp7MywxLA0Key0xOH0s

MCwwLDB9LA0KezEsMH0NCn0sMjEsMCwwLDAsMCwwLDEsMCwwLDAsMSwwLDAsMCww

LDAsNCwwLA0KeyJVIn0sDQp7IlUifSwiIiwyLDEsMCwwLDAsMCwNCnszLDAsDQp7

MH0sIiIsLTEsLTEsMSwwfSwNCnszLDAsDQp7MH0sIiIsLTEsLTEsMSwwfSwwLDAs

MCwNCnswLDAsMH0sDQp7MSwwfSwwLDAsMCwwfQ0KfSwNCnsxLA0KezlhNzY0M2Qy

LTE5ZTktNDVlMi04ODkzLTI4MGJjOTE5NWE5NywNCns0LA0KeyJVIn0sDQp7IlUi

fSwwLCIiLDAsMH0NCn0NCn0sDQp7MH0sMCwxLDAsDQp7MSwwfSwwfQ0KfSww}

Причем в соседнее идентичное поле - ничего не дописывается. Лечиться полной очисткой поля и переоформлением его в макете.

Такие дела.

И так у меня в 3- х полях, что приводит к тому, что 100000-строчный таб док. отжирает 2 гига оперативки и весит на винте 600 метров.

Счаст конвертну эту base64, вдруг там че годное

Будте осторожны, когда оформляете макеты, не копируйте ячейки откуда попало

Ничего интересного там не оказалось, вот такая ботва, такое ощущение, что вложенная ячейка

?2,1,381ed624-9217-4e63-85db-c4c3cb87daae,
{
{9,
{"Pattern",
{"D","D"}
},
{
{
{10,1,
{3,4,
{0}
},
{3,4,
{0}
},
{6,3,0,1},0,
{3,3,
{-22}
},
{3,4,
{0}
},
{3,4,
{0}
},
{3,3,
{-7}
},
{3,3,
{-21}
},
{3,1,
{-18},0,0,0},
{1,0}
},21,0,0,0,0,0,1,0,0,0,1,0,0,0,0,0,4,0,
{"U"},
{"U"},"",2,1,0,0,0,0,
{3,0,
{0},"",-1,-1,1,0},
{3,0,
{0},"",-1,-1,1,0},0,0,0,
{0,0,0},
{1,0},0,0,0,0}
},
{1,
{9a7643d2-19e9-45e2-8893-280bc9195a97,
{4,
{"U"},
{"U"},0,"",0,0}
}
},
{0},0,1,0,
{1,0},0}
},0

Поискать
381ed624-9217-4e63-85db-c4c3cb87daae
9a7643d2-19e9-45e2-8893-280bc9195a97

в базе, али ну его?

381ed624-9217-4e63-85db-c4c3cb87daae 'nj xnj pf nbg&

это что за типа?

(7) Это GUID

(7) Откуда я знаю?

Могу образчик mxl сбросить

(8) сделай ЗначениеВСтрокуВнутр и покури. Или ЗначениеИзСтрокиВнутр с этой шляпой

гуид данных  которые используешь  или откуда то взявшийся?

(10) ну скинь, тока я счас смотреть не буду, если только завтра

Все, отбой, это не данные, это же из макета, а не из таб дока строка

просто типы тоже гуидами кодируются, например вот интересно: http://infostart.ru/public/71130/#Pro_bystrye_massivy

я так делал из массива ТЗ и обратно - вполне моментально получается

Простите за Вебфайл конечно, но искать другое лениво
http://webfile.ru/6160182

Я дятелъ, короче.
Вместо того, чтобы макет поправить, исвращался с выносами на сервер, Временными хранилищами, и.т.д.. А ведь хотел глянуть, но не верил и некогда было.
Некогда думать, надо пилить. Не всегда срабатывает

это не может быть настройкой границ и форматов всяких?

нет

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

Долгие хитрые манипуляции с временными хранилищами, таб. доками, деревьями значений, и вуаля - у нас есть 1С -ка, занимающая 600 метров оперативы и txt файл на 12 метров.
Жалкие.
12 метров.
И хоппа, при попытке его прочитать, 1С падает с нехваткой памяти.

Причем, если прочитывать на пустой 1С-ине - все нормально.

Это если ЧтениеТекста, а если:

ТекстовыйДокумент=Новый ТекстовыйДокумент;
ТекстовыйДокумент.Прочитать("b:\tmp.txt"); //отжирает 30 метров ОЗУ
ТекстДляЗаписи=ТекстовыйДокумент.ПолучитьТекст(); //Падает
ТекстовыйДокумент=Неопределено;

Я думаю, что после диких операций с объектами - память фрагментирована и чисто некуда аллокейтить 24 мегабайта ОЗУ непрерывным блоком, не?

Но почему
ТекстовыйДокумент.Прочитать("b:\tmp.txt"); //отжирает 30 метров ОЗУ

нормально?

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

Пичаль. Столько мест обошел и завалиться буквально на самом конце, на простейшем.

ха

На какой итерации упадет?

Ф = "ф";
Для Сч = 1 по 100 Цикл
 Сообщить(Сч);
 Ф = Ф + Ф;
КонецЦикла;

со строками у 1с все фигово

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

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

причем чтениеТекст.ПрочитатьСтроку() а не Прочитать(). ну и постепенная обработка.

типизированная ТЗ занимает намного меньше места, чем строки

кстати, наверное там память просто сильно фрагментируется

(29) 2^100 - порядка 1152921504606846976 ТБ... что значит у 1с не все в порядке со строками???

(26) у меня падает на 27-й итерации, длина строки 67 108 864, памяти у процесса может быть аж до 2 гб, ЕМНИП

(1) я хз что у тебя с табличным полем, но писал обработину для декларации (скока строк не считал, но оптовая на регион), там проблем таких не было... о_О

Попробую тупо зааллокэйтить 12 метровую строку.

(37) к (36)

Вывел Предупреждение () на 3 секунды - та же хрень.

(39) реально, через чтениетекста фигачь в ТЗ. у меня так ТЗ с >1м строк (где-то по 60 байт по сумме полей) загрузилась нормально

(37) а тебе реально нужно было 37 метров строки анализировать? О_О

или тебе прям 1 кусок нужен?

(43) это тест такой

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

(23) ну если считать что 12 метров текста, в формате юникод - 2 байта на каждый символ, то 30 метров оперативы уже гдето близко. потому как там еще промежуточные наверняка переменные хранятся..

(46) да, падает если Прочитать()

Надо его запихать в
Документ.ВыгрузкаРегламентированныхОтчетов

Самое забавное, что при запихивании в типовой текстовый реквизит приходит падение при записи дока, поэтому там особый, ХранилищеЗначения реквизит с максимумом сжатия.

если только хранить, то Новый ДвоичныеДанные(<Имя файла>) и в хранилище...

все-таки пятница

(51) Тяжко корежить типовые механизмы.

Итак уже отдельный модуль на печать отчетности на сервере запилен.

Счаст попробую кусками по 1000 символов читать и приращать переменную

(55) не взлетит

максимум что - точнее определишь момент падения

Логика мне говорит, что не взлетит, но я и в (0) не верил!

Тех же щей.
Ну его к херам, этот черный гроб, сделаю через Двоичные

Йессс!
Отс^%&&си, гребанный диспетчер памяти!

(60) чо?

(61) Чо, чо.. Забил я на строку, сделал через Двоичные, все отрабатывает.

(62) а, ну ясен фиг. туда и гигабайты вроде как засовываются...

я думал со строкой обманул