Медленное сложение строк #779314

Добрый день, коллеги. Возникла непонятная ситуация. Сложение строк на тороне сервера происходит очень долго. Конкретно: Данная операция выполнившись 152899 раз заняла 72,663834 секунды и находится на первом месте в замере производительности. Вторая в списке тяжелых конструкций: Соответственно 152899 раз и 72,093324 секунд. Данное с Отдельное тестирование сложений тысячи строк из ста символов выдает что данная операция делается меньше секунды. С чем может быть связано подобное поведение?

с обращением через точку

С преобразованием типов.

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

ИДПрайса Изначально имеет тип "Строка"

Отдельное тестирование сложений тысячи строк из ста символов выдает что данная операция делается меньше секунды. А теперь "меньше секунды" умножь на 152. Ибо ты тестировал тысячу, а у тебя - 152 000.

сложение строк не сильная сторона 1с. попробуй записьтекста

Неправильно написал, виноват. Там идет цикл 150000 раз. Собирается строка из строк по сто символов. На каждой тысячной итерации строка обнуляется. Вот это полное действие делается меньше секунды

рекомендую почитать

Вот часть кода: Как видно переменная ТекДатаВремя изначально имеет тип строка, но при этом Стр = стр + "', '" + ТекДатаВремя + "', '"; выполнившись 50000 раз затратило 29,4 секунд. Это к вопросу о приведении типов

Спасибо, изучаю

прав.

А просто ЗаписьТекста хуже?

Чем больше строка - тем дольше добавление.

ЗаписьТекста (добавление без перевода строки) + ЧтениеТекста поможет

Стр = Стр + "текст"; Особенности работы с памятью. Область памяти под переменную динамически увеличивается. Накладные расходы на эту операцию составляют основное время, имхо.

вроде она через память не работает, а только через файл

скорее всего нечего не увеличивается. Просто стр и "текст" теряют ссылки и уходят в муссор, а под новую итоговую строку выделятся нужный объем памяти. И так очень много раз. От чего сборщик муссора пыхтит. Скорее всего и процесс отъедает ядро проца полностью

Тоже вариант. Точно только у разработчиков платформы узнать можно )

стр = стр + стр в цикле очень быстро сжирает память, так как ищет непрерывный кусок для результата, даже сборщик мусора не помогает. ну и тормозит.

Если версия платформы + режим совместимости позволяют, можно использовать СтрСоединить. Метод специально для этого и делали.

Здесь есть сравнение

Какая любопытненькая статейка :)

Сравнил, кстати. ЗаписьXML и СтрСоединить сравнимы по скорости )

Да, действительно, на первое место вылезли уже другие операции. Огромное спасибо) Как говорится век живи - век учись)

Подскажите еще, пожалуйста. Что эффективнее, выполнение одной большой инструкции Соединение.Execute(ТекстЗапросовInsert); или нескольких поменьше?

есть нюансы

можно вообще отправить большой инсерт асинхронно и дальше работать

Что за нюансы, подскажи пожалуйста

Как это выглядит?

Сборщик мусора в 1С? Отличные грибы!

А что, в 1С его нету?

Для начала покупаешь IIS

Нет конечно. Только счётчик ссылок в каждом объекте. Память освобождается сразу при освобождении объекта. Циклические ссылки висят до смерти процесса.

Кто/Что заботится об очистке памяти? 1С? или всё-таки ОСь?

Мне почему-то казалось, что это простейшая реализация сборки мусора, но да, по формальному определению оно ей не является :(

Сделал отправку одного большого запроса на сервер. Стало быстрее чем несколько меньших

получается и на сервере такой подход? Тогда понятно откуда неизбежные утечки памяти. Еще скорее всего нет никаких механизмов дефрагментации памяти так как этим обычно занимается GC По идее это было GC, если бы запускалось в отдельном процессе, а тут видимо interceptor в тех местах где пропадает ссылка. На сколько помню в objective C похожий подход.

Это не сборка мусора, а процесс управления кучей памяти. Он ничего никуда не перемещает, а просто или выделяет память или освобождает. Что же касается строк, то упирается всё не в выделение памяти, а в копирование предыдущего значения строки, в новое место. Причём, со сложением строк в javascript те же "тапки" - тормозит так, что хочется в экран плюнуть.

почти везде так будет где строки иммутабельны. К примеру в джаве есть мутабельная и иммутабельная строка.

в JS можно использовать массив, должно быть быстрее

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

не все так однозначо. Когда мы в цикле складываем 2 переменных типа строка и присваиваем - это значение 1-й переменной, } то выделяется область под результирующую строку куда копируються данные 2-х строк источников и так много раз. И GC тратит ресурс на освобождение памяти от 2-х исходных строк. Когда используется буфер, то в нем заранее выделена память под всю результирующую строку. В случае с JS некое подобие работы с буфером это создать массив где лежать все кусочки строки и 1 операцией сцепить все строки. В таком случае интерпритатору очень просто определить размер результирующей строки. var arr = [] arr.join("") ps. Сейчас браузеры пытаются оптимизировать 1й вариант и не везде получится увидеть разницу.

Сам то понял, что сказал?

естественно, если не ясно детальное объяснение, скажу короче. В 1 варианте операций выделения памяти и сборки мусора больше.

1 вариант: - В каждой итерации выделится и станет "муссором" память под "foo". - Каждую итерацию будет выделена и станет "муссором" память под состояние переменной "а". Размер переменной "а" будет увеличиваться с каждой итерацией. 2 вариант: - В каждой итерации выделится память под "foo". - 1 раз после цикла выделится память под итоговую строку после чего память выделенная под "foo" станет "муссором"

Проблема очистки стоит в этих ваших виртуальных машинах. В наших православных Дельфи проблемы очистки нет. Есть проблемы утечки. Которую контролят спецутилиты на этапе разработки. Что до строк, то есть 3 стратегии конкатенации: 1) Реаллокация на каждый чих 2) Программер сам знает (знает только программер, менеджер памяти никогда этого не знает) какой длины у него результирующая строка. Он выделяет память сразу и пишет в нее. Простейший пример BASE64 с ее 4/3 размером. 3) Мудрый менеджер памяти/среда разработки выделяет память под строки блоками, байт по 8000, к примеру, как это делает TStream в Дельфи. Самый годный вариант, кстати. Но я бы буфер сделал бы больше, по 64 Кбайта норм. Это все, что нужно знать в этой теме. Все остальное - лишнее.

Обджект паскаль может и  был не плохим языком, но факт остается фактом, что этот ЯП самоликвидировался и именно из за конкуренции с языками работающими на виртуальной машине(java, c#). В джаве нет таких проблем, там и оптимизатор умный и девелопер может использовать StringBuilder и сам указать capacity этого билдера/буфера. Есть область памяти называемая пулом стрингов, где строки могут кешироваться и при повторном использовании литерала память не будет выделяться (в примере для JS под "foo" память выделится 1 раз) В джава так же есть возможность напрямую управлять памятью и эта память будет не под управлением виртуальной машине, мы такое в бигдате юзаем.

Да удобство работы с динамическим выделением памяти в объектном паскале не очень по сравнению с Java/C#. Требует более высокого скилла прогов (как и C++), но конечный результат для пользователей чреват требованием апгрейда железа.