Те версии программ взаимодействия «клиент-банк», которые работают с текстовыми файлами, при больших объёмах думают долго, последовательно обходя файл построчным чтением текста. Что можно сделать:
1. Проанализировать наполнение текстового файла, стабильность разметки, разнообразие специфических символов (особенно в назначениях платежей).
2. С помощью регулярных выражений или простым СтрЗаменить привести текст к виду xml.
3. Исходя из разметки (т.е. тегов), используемых в ваших файлах, сделать xdto-объекты ровно той структуры, которая отвечает разметке. Правильно объявляем типы свойств. Динамически создаём и подгоняем xsd под файл xml.
4. Использовать сериализатор для быстрого чтения и получаем, например, СписокXDTO, каждый объект которого есть платёжная транзакция со своими xdto-свойствами.
5. Выполнить чтение из полученных объектов. От цикла всё равно не уйти, но это в разы быстрее благодаря сериализации п.4
UPD: Выкладываю обработку, иллюстрирующую эту технологию. Рассчитана на интерфейсно-пользовательско-клиентское и на серверное применение. Не является законченным решением, т.к. вся работа доходит до чтения объекта «СписокXDTO» и заполнения таблицы значений — поэтому, коллеги, вы можете сделать собственные обход и обработку результатов чтения.
Ахтунг! Недостаток способа в том, что он чувствителен к наполнению и структуре файла, поэтому при битых, экзотических или изменившихся текстовых входных данных xml-вариант просто не прочитается, и эту уязвимость придётся «лечить» каждый раз очень внимательно. В предлагаемую обработку встроена возможность делать свои замены с помощью регулярных выражений, и эти замены могут сохраняться в настройках чтения.
На моих данных, типовой «Клиент-банк» сперва думал около часа, тогда как мой вариант работал 5-7 минут; а потом и вовсе пришлось заменить, т.к. типовая обработка стала вылетать и виснуть. Надеюсь, вам удастся ускорить работу примерно так же. В принципе, обратная выгрузка может быть сделана аналогично — запись в xml средствами xdto и обратная конвертация в текст с заменой на общепринятую разметку.
Также обработка может пригодиться как пример работы с динамическими xsd.
(1) Чем же слабовата? Идея ясна? Ясна. Воплощение — у каждого своё, как наполнение файлов Клиент-банка своё. Имхо, это лучше, чем вывалить свою узкоспециальную обработку и читать потом жалобное «а у меня не фурычит».
Более приятно было бы видеть пример в картинках с пояснениями.
Интересно, что это за файл, который обрабатывался клиент-банком 1 час??
(3) Теперь пример есть.
(4) Вот такие у нас файлы платежей. Много, из разных банков по всей стране, от физлиц и юрлиц. Крупная компания…
(5) «много» — это ни о чем… Конкретнее, озвучьте, плиз, много это сколько? около тысячи платежей? сотни? десятки тысяч?
и как-то мне сомнительно, что последовательное чтение и независимая обрботка платежей будет медленнее чем все это преобразование в xml и прочие обработки исходного файла…
Кстати, обнаружено-таки побочное явление: здорово кушает оперативку на точке выполнения (в моём случае на клиентской машине). Был случай «Недостаточно памяти». Есть подозрение, что текстовые переменные 1С всё же не совсем оптимально гоняет; впрочем, идею это не отменяет. И думаю, что СтрЗаменить ресурсоёмка, надо б везде заюзать внешние RegExp’ы.
(6) Не поверишь, быстрее. А вот недавно поставленный эксперимент по сериализации меня удивил. Решил я померять, как быстрее массив в таблицу значений перегоняется — через сериализацию Array, один вызов СтрЗаменить, конкатенацию и десериализацию уже в ValueTable; или циклом. И что? И оказалось, что банальный цикл по массиву с добавлением строк в ТаблицуЗначений оказался в 1.5 раза быстрее всех этих строково-xmlных игрищ. Так что, замечание в целом верное, есть в работе с xml ситуации проигрыша по скорости, только не в случае вышеприложенной обработки.
Всеравно ни о чем. возьмите файл выписки большой. прогоните его штатно с замеромпроизводительности и через вашу приблуду. насколько быстрее..?
(7) Какие-то сказки рассказываете про то что некий «клиент-банк» работает медленнее некой вашей обработки.
А где факты?
Что за «клиент-банк»? Что за конфигурация? Какая версия? Какая платформа? Где цифры замеров?
Например, взять «клиент-банк» из БП 3.0. Раньше в качестве «построчного считывания» текстового файла использовался объект ТекстовыйДокумент и его метод ПолучитьСтроку(). Что естественно сказывалось на скорости считывания — ибо на каждую ПолучитьСтроку(N) всегда читались заново все строки до N.
Недавно разработчики устранили эту нелепость — теперь используется объект ЧтениеТекста. Скорость считывания файла выроста на порядки.
(9) Батенька, вы тон-то сбавьте. Обычная БП 2.0, обычный встроенный Клиент-банк. И обычный файлик реестра платежей, на котором он уже в первые дни работы компании в 2012 году стал думать час и более, об чём я писал во первых строках публикации, а моя думала минуты, ну 10-20 минут максимум. Точные замеры тогда не делались, а теперь невозможны, ибо штатный Клиент-банк просто виснет. А мой блок — работает. Вот такие факты. ЗАО «Техосмотр», миллионы платежей по РФ в день. Резать файлики и устраивать тесты мне, пардон, теперь недосуг.
Рад за разработчиков 3.0, что они наконец тоже нечто предприняли и воспользовались ЧтениемТекста. Но, см. выше, в 2012 про 3.0 никто не слыхивал, да и сейчас пока на 2.0 почти все сидят.
Впрочем, я красивую идею подкинул, а уж кто воспользуется и кто будет продолжать мучиться — каждый решает сам.
А то, знаете, некоторые и xml-файлы чёткой структуры до сих пор читают объектом ЧтениеXML, поэлементно в цикле.
(10) ну правильно в БП 2.0 это никто не исправлял и исправлять не будут. Ибо жить БП 2.0 осталось не долго.
> Те версии программ взаимодействия «клиент-банк», которые работают с текстовыми файлами, при больших объёмах думают долго, последовательно обходя файл построчным чтением текста.
Вот это и есть сказки. Я уже объяснил почему в предыдущем сообщении.
> А то, знаете, некоторые и xml-файлы чёткой структуры до сих пор читают объектом ЧтениеXML, поэлементно в цикле.
И возможно правильно делают. Попробуйте прочитать гигабайтный файл XML (наприме файл обмена) с помощью XDTO. Боюсь что вас будет ждать сюрприз)
(11) Гигабайтные файлы не читал. Вы намекаете, что где-то не хватит ресурса? Где, какого? Если знаете, расскажите, а то я весь наивный юноша и верю, что 1С с xdto работает экономно да на сервере… Тоже сказка?
(это я не ёрничаю, а правда интересно)
(12) Проблема в том, что объект XDTO размещается в оперативной памяти. Причем весь объект сразу.
И при этом памяти под объект почему-то требуется больше. Если учесть, что под 32-разрядный процесс выделяется только 4Гб памяти, то с вероятностью почти 100% при чтении гигабайтного XML сервер упадет с ошибкой нехватки памяти.
На 64-разрядном сервере файлы считать можно будет чуть побольше по размеру. А если учесть, что сервер вообще должен еще и другой полезной работой заниматься, а также фрагментировать памяти, то лучше забыть про идею считывать огромные файлы в XDTO.
(13) Понятно. Грустная информация, но учту. А я-то верил в некое кэширование…