Пишу интеграционный модуль в виде внешней обработки. Столкнулся с тем, что при увеличении объёма данных сильно падает производительность. Сделал замер производительности и по нему получилось, что больше всего времени занимают процедуры и функции с использованием СтрЗаменить. Как можно ускорить замену символов в строках? Регулярные выражения не предлагать, производительность только падает.

Возможно подготовить данные таким образом, чтобы не использовать СтрЗаменить? и почему так много стрзаменить?

(0) используй питон, Люк

(0) сменить логику на меньшее число вызовов СтрЗаменить.

(0) небось СтрЗаменить используешь для строки длиною в два тома войны и мира?

(4) Нет, дружок, для коротких строк.

Чет не верю. Давайте скриншот

(5) очень странно. Если не использовать длинющие строки, то нужно постараться, чтобы сделать строковые функции узким местом

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

(6) Здравствуйте, я тоже атеист.
А по теме писать можно или ты так, "поневерить" зашёл, Ёзжик с Ошибкой?

(7) Сам в шоке. До замера грешил на конкатенацию, но не оно.

(10) какой формат должен получиться на выходе?

(8) Что-то похожее и получилось, около 300 тысяч строк в итоговом файле, на каждую строку минимум раз, а то и 5 СтрЗаменить.

(11) Текст.

(13) это понятно, структура какая? XML, JSON, CSV, YAML...?

JSON

(12) Пристрелить.

(16) Этот парень был из тех, кто просто любит жись.

(12) покажи как формируешь строки

(12) Регулярные выражения может стоит попробовать?

(19) Стоит попробовать пройтись 1 раз по итоговому тексту и собрать итоговую строку из массива кусков, возникших при замене через СтрСоединить()

(19) У него вера в то, что регулярка не поможет. Он так и написал : "не предлагать"

(16) из тюльпана

(10) погреши еще на неявное приведение типов, погромистик. Ссылки к строке там и все такое.

Автор вступил на скользкую тропинку, на которой можно получить Орден ЛивингСтара.

(21) не дочитал до этого места :)

Интеграционный модуль чего? Сферического коня в вакууме?
А как насчет того чтобы вообще от этого избавится?
Зачем 100500 раз преобразовывать одно и то де, если это преобразование можно где-то сохранить?

Кажись и правда ТС пристрелили...

Эх, а я только хотел узнать почему на него очень сильно повлияла серия книг "Хроника Страны Мечты" писателя современности Эдуарда Веркина. Особенно вторая книга.

(0)
чистая статистика
платформа 1с8 может вполне быстро сформировать 300к строк текста.
80 процентов спрашивающих на форуме - полные идиоты. отсюда и недоверие к сказанному.
если у Вас увеличением объема обрабатываемых данных нелинейно увеличивается время обработки
то Вы не умеете мыслить категориями множеств. те в работе в бд - дилетант.

Попробуйте привести участки "медленного" кода.
НО будьте готовы  к критике.

(0) О чем идет речь? Если юзаются действительно большие объемы текста, то СтрЗаменить "в лоб" юзать нельзя. Есть специальные алгоритмы представления и работы с большими строками, можно погуглить rope. Возможно, придется отказаться от 1С в пользу чего-то более быстрого.

(28) А давай проверим?

>> Регулярные выражения не предлагать, производительность только падает. - хм, какие Ваши доказательства (с) Терминатор Арни

Вот есть у нас кусок кода, который создает полгиговый текстовый файл:
&НаКлиенте
Процедура ПодготовитьФайл(Команда)
    Данные="Вы полны идиотских стереотипов"+Символы.ПС;
    МассивСтрок=Новый Массив;
    Для Счетчик=1 По 10000000 Цикл
        МассивСтрок.Добавить(Данные);
    КонецЦикла;
    Результат=СтрСоединить(МассивСтрок);
    Запись=Новый ЗаписьТекста("e:\tmp1\data.txt",КодировкаТекста.UTF8);
    Запись.Записать(Результат);
    Запись.Закрыть();    
КонецПроцедуры

И вот кусок кода с заменой символа на 1С и замером миллисекунд:
&НаКлиенте
Процедура ВыполнитьЗамену(Команда)
    Чтение=Новый ЧтениеТекста("e:\tmp1\data.txt",КодировкаТекста.UTF8);
    Результат=Чтение.Прочитать();
    ВремяНачала=ТекущаяУниверсальнаяДатаВМиллисекундах();
    Результат=СтрЗаменить(Результат," ","_");
    ВремяОкончания=ТекущаяУниверсальнаяДатаВМиллисекундах();
    Сообщить("Выполнено за: "+Строка(ВремяОкончания-ВремяНачала));
КонецПроцедуры

И вот кусок кода с заменой символа на Delphi и замером миллисекунд:
procedure TForm1.Button1Click(Sender: TObject);
var
  Чтение: TStringStream;
  Результат: String;
  ВремяНачала: Cardinal;
  ВремяОкончания: Cardinal;
begin
  Чтение := TStringStream.Create();
  Чтение.LoadFromFile('E:\tmp1\data.txt');
  Результат := Чтение.DataString;
  ВремяНачала := GetTickCount;
  Результат := StringReplace(Результат, ' ', '_', [rfReplaceAll]);
  ВремяОкончания := GetTickCount;
  ShowMessage('Выполнено за: ' + inttostr(ВремяОкончания - ВремяНачала));
end;

В 1С замена в полгиговом тексте выполняется за "Выполнено за: 945"
В Delphi замена в полгиговом тексте выполняется за "Выполнено за: 828"

(0) Рома штоль ссыкует?

Меня забавляют эти люди.
Они живут в своем мире, пишут "не лучшие" алгоритмы, а потом открывают для себя SQL, который вывезет почти любую копроархитектуру запросов за счет своих оптимальных алгоритмов.
И они начинают считать SQL волшебным ящиком. И херачить в него любую дичь, временные таблицы из ТЗ, вот это все. Потом они открывают для себя индексы. И они решают, что волшебный ящик то с волшебной палочкой и начинают херачить индексы везде. Даже не задумываясь, что волшебства не бывает.
Так и тут. Волшебства нет, на каком бы языке ЯП ты не написал код, использовал ли регулярные выражения, процессору нужно пройти хотя бы 1 раз все эти полгига памяти.

(27) тож интеграционный мегамодуль, вдруг сопрешь...
>> Вы не умеете мыслить категориями множеств. те в работе в бд - а обработка текста тут к чему?

(34)
проблема одинесников в видении обработки данных построчно и по-элементно. если "видеть" структуры данных шире, то будут совсем другие алгоритмы и способы их реализации в 1с.

(35) в целом, если мыслить шире-обширно, то будет больше профита

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

(37) Я не готов воспринимать ваши сообщения всерьез, поэтому писать мне бессмысленно, я в будущем не отвечу.

(37) а че так 8-ка мрачно ворочается? сил вт не хватает? или с 8-кой что-то не так?

(35) "в видении обработки данных построчно и по-элементно. если "видеть" структуры данных шире, то будут совсем другие алгоритмы и способы их реализации в 1с."
- такие ширшее алгоритмы требуют другого подхода в первую очередь к генерации исходных данных.

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

(36)
речь была в контескте проблемы (0) " увеличением объема обрабатываемых данных нелинейно увеличивается время обработки".
но с изменением с 1c 8.16 многие алгоритмы стали стали работать нелинейно от объема данных .

(38) понял.

(41) то есть если я на клюшках еще задумывался для своих мелких клиентов чтобы ну хотя бы терпимо было по времени, то на восьмерке для этого типа клиентов - вообще пофиг будет на вытяжку запросами, тянуть по привычке через точку и выборками и зашибися...?

(43) В целом - да, но лучше не надо.
Как ни странно, мифы о тормознутости 8-ки преувеличены. Ты бы и сам смог в этом убедиться, если бы не ленился и попробовал в восьмерку.
90% тормозов в моей памяти - это косяки в данных, либо в программной настройке сервера, либо в аппаратном составе сервера, либо в доработках.
9% - это всякие хитрые штуки в типовой, например crossjoin план запроса, которые оперативно правятся 1С-кой.
Ну и где то 1% жалкий процент тормозов - это платформа.

(31) сделай заменить в цикле 100000 раз - разница будет а разы

(31) ну разница-то все же есть. Впрочем, речь не об этом. Речь о том что автор не написал сколько у него операций реплейса и на каких объемах. Если у него мегабайтные строки и операций десятки или сотни то в тормозах-то ничего странного может и нет. И тут надо думать куда уехать с больших строк.

Проблема стандартной работы со строками - там скорость сильно зависит от длины. Если использовать rope для хранения строки - там такой сильной зависимости нет. В принципе, на Дереве значений шнур можно сделать.

(20) Еще предложи распараллелить обработку строк в кучу потоков.
Потоков 100 так берем и делим 300к строк на 3к в каждом потоке где СтрЗаменить

(48) Ну кстати тоже вариант. Только надо будет позаботиться, чтобы заменяемая строка не разбилась между чанками.

если образец на замену может быть произвольным и заранее неизвестно каким, тогда это может создать определенные сложности :)

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

Где замер то?

чтобы ускорить работу в данном случае нужно от 300 000 до 1 500 000 вызовов СтрЗаменить заменить на меньшее количество.
то есть сначала объединить куски текста и потом заменить в результате а не менять в каждой подстроке с последующим объединением.
пробуйте.

(53)+ Это однозначно поможет. Кроме того, возможно, стоит организовать потоковую обработку файлов через ЧтениеТекста и ЗаписьТекста с быстрой обработкой буфера.

(0) > Столкнулся с тем, что при увеличении объёма данных сильно падает производительность.
Нелинейно, что ли?

Если нелинейно, то стопудово проблема в руках. Код в студию.

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

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

Чувак похоже XML руками собирает :))))

(58) ага , По символьно)

(58) почти. JSON он руками собирает (15)

(60) даже это можно делать без таких затыков в производительности.