Добавил версию на строках: https://github.com/Athari/Tmp-StringBuilder...elphi/Unit1.pas
Обновлённые цветастые таблички: https://github.com/Athari/Tmp-StringBuilder...ingBuilder.xlsx

Забавная эта штука дельфи -- код, который согласно любой логике работать не должен, умудряется работать быстрее того, который по любой логике более шустр.  То есть дельфи всё ещё сливает дотнету, конечно, причём в некоторых тестах раз в пять, а если выигрывает, то почти всегда незначительно, -- но теперь хотя бы нет ужасающего стабильного разрыва в несколько раз во всех тестах. Причём даже потребление памяти исправилось, на пике вышло 750 метров. Надо признать: строки оптимизированы хорошо.

Но почему в дельфи такое медленное создание объектов (ускорение в первой четверти таблицы в 2-3 раза) -- для меня остаётся загадкой. В коде нет ничего очевидного, что может так тормозить.

каких еще объектов?

потому что по-честному не создается копия результирующей строки, о чем я говорил выше

скорее, менеджер памяти

результаты в обновленной таблице у Delphi (+) какие-то убогие. оставил циклы прежними, не стал по-хорошему их переписывать?

Это сообщение отредактировал(а) fd00ch - 13.5.2013, 22:22

В реальных же проектах нет необходимости по миллиону раз, и даже по 10 тыс. раз выполнять конкатенацию строк в цикле. По крайней мере мне не приходилось. Максимум раз 10-20 в цикле. И у меня часто используется функция StringReplace().

@fd00ch


Циклы другие? Странная оптимизация (в шарпе и плюсах такая оптимизация не прокатит, скажем), ну да ладно, сейчас попробую.


Хм, что-то сорцы не высосались. Ну вот декомпиляция StringBuilder из .NET 3.5 (выкинул комментарии и сериализацию): https://gist.github.com/Athari/5570726
Вот из дельфи: https://gist.github.com/Athari/5570745
В дотнете ещё всякая потокобезопасность накручена, так что ещё медленнее должно быть.


Managed code: "Стерлять в ногу -- нельзя!"
Unmanaged code: "Стрелять в ногу -- здесь!"
Собственно, unsafe код -- это работа с указателями. Про платформы не фантазируй, ибо кросс-платформенность получше, чем у дельфи.


Не улавливаю логику. Прочитай прокомментированное внимательнее...


Здесь опечатка: "простых" следует читать как "пустых". У Белтара была ошибка в коде, из-за которой складывались пустые строки. Поэтому поведение приложения в этом случае мне известно.


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

@Akella


У нас нет реальных эквивалентных проектов на разных технологиях, на которых можно эффективно проводить сравнения, поэтому единственное, что остаётся -- маразматичные синтетические тесты.

@fd00ch


Гы, и правда:

Но начерта так сделали?

В Delphi тоже, не переживай. Потому код и тормозит...

Дык, ты создаешь и уничтожаешь 100 млн объектов. ничего удивительного, что элементарный кодвыполняется 4-5 секунд, инициализация-финализация не дается бесплатно, но тут - и не слишком дорого. NET, кстати, не создает ли в реале 1 билдер, а потом 100 млн раз делает Clear и использует его снова и снова?))

Очевидно, потому что в 99.9% случаев внутренний буфер имеет бОльшую длину

Добавил версию с "оптимизированными циклами": https://github.com/Athari/Tmp-StringBuilder...elphi/Unit1.pas
Результаты: https://github.com/Athari/Tmp-StringBuilder...ingBuilder.xlsx

В левом нижнем углу страницы в экселе добавил табличку с соотношением скоростей. Процент означает потерю/прирост времени при переходе с Delphi на .NET. Если процент меньше нуля и зелёный -- победа за дотнетом, если больше нуля и красный -- за дельфи. В первой четверти победила дельфи (впрочем, дотнет на операторах здесь тоже будет летать, но мерять лень). В остальных практически ничья, правда наблюдается закономерность, что дотнет заметно лучше на небольших строках, а дельфи незначительно -- на больших, но за счёт того, что суммарно по времени на большие строки уходит больший процент времени, ситуация выравнивается. В реальных приложениях стомегабайтные строки --  это, конечно, большая редкость; равно как и слияние "а" + "аа" на StringBuilder.

Что дельфи настолько просаживается на for-in, что это оставляет в тени остальной код -- это забавно. Ну нельзя так писать компилятор, чтобы синтаксический сахар в самых тривиальных и часто используемых случаях умудрялся тормозить код в два раза.  

@fd00ch


Не вижу упоминания потоков в сорцах TStringBuilder.


Какая инициализация-финализация? Выделить блок под билдер, выделить блок под буфер, записать три dword'а, удалить блок буфера, удалить блок билдера. Выделение и удаление блоков, как мы уже выяснили, быстрое. Тогда в чём тормоза?


Потери 50% памяти -- незначительная погрешность в современных реалиях, особенно учитывая, что большинство строк умрёт вскоре после создания. Собственно, всеми любимые vector<T>/List<T> исходят из той же логики.


Дотнет не настолько умный.  Ну и можно проверить и вынести билдер за цикл -- тесты будут пролетать моментально.

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

Ищи эти упоминания в подкапотных low level функциях для работы со стрингами

Ты описал действия для некоего стрингбилдера, который является "потомком" record, потомки TObject выполняют еще и доп.код

Ну а я пока не верю, что .NET реально создает и уничтожает 100 млн объектов за 600 мс, умудряясь еще и полезную работу выполнить (в одном потоке))). Где-то он обязан филонить. Вынеси за пределы цикла - посмотрим))

Хотя, нет - 100 млн объектов создается только в первом проходе - на это .NET тратит минимум 4.5 сек (с полезной работой). в это поверить еще можно...

Тогда сравнивать Delphi и .NET описанным сценарием изначально не имело смысла - тупо из-за накладных расходов в Delphi при создании/уничтожении объектов (100 млн итераций TObject.Create.Free занимает 4.5 сек, TStringBuilder.Create.Free - аж 9 сек). Хотя, на последних проходах (где создается мало объектов) Delphi с TStringBuilder и грамотными циклами вполне мог бы потягаться с .NET ;)

Это сообщение отредактировал(а) fd00ch - 14.5.2013, 00:53

@fd00ch


Какой доп. код? Не вижу в конструкторе TObject ничего.


Сделал полное повторное использование. Ускорилось в два раза в случае .NET 4.5, в полтора -- в случае .NET 3.5.

Отсутствие GC.
Выделение памяти без сборки раза в 4-5 медленнее.

Добавлено через 5 минут и 17 секунд

В java для этого есть StringBuffer(потокобезопасен) и StringBuilder(не потокобезопасен - теперь рекомендуется).

@serger


Строки при конкатенации через оператор+ спамят менеджер памяти только так. Дельфи в этом режиме работает достаточно быстро, дотнет -- загибается. Или строки особенные какие-то?

Athari, не совсем понял.
Вообще строки - это такая запутаная штука, как я понимаю. В каждом языке стараютя посвоему "извратиться". Наверное это не очень удачный способ померяться.

Добавлено через 10 минут и 45 секунд
http://store.embarcadero.ru/catalog/product/1
Если этого достаточно, то не так и дорого, но они болванки продают за 1000 р!!!

@serger


На дельфи сложить 32 раза строки оператором+ (то есть выделить память под строки длины 1, 2, 3, 4, ..., 32) быстрее, чем сложить билдером (создать билдер, создать три буфера длиной 16, 32 и 32). Это странно.


Starter нервно курит в сторонке от одного вида Visual Studio Express: совершенно бесплатно, ограничений на доход нет; разработка под десктоп (WinForms, WPF, WinAPI), метро, веб (ASP.NET, Azure), Windows Phone, игры для десктопа и XBox 360 (XNA); C#, C++, VB; 32, 64-bit; SQL Server. Собственно, Delphi Pro (14 091.72 руб) сосёт и причмокивает у Visual Studio Express (0 руб). (Средства отладки более урезанные, да, но возможностей всё равно на порядок больше.)

Опен-сорса под дельфи никогда не будет. Поэтому не будут каждый день появляться десятки новых библиотек, как на других языках. А что в какой-то там версии дельфи была бесплатная редакция -- это жалкая попытка Багланда увеличить аудиторию дельфи и сплавить её подороже (собственно, такова их официальная позиция).

Это сообщение отредактировал(а) Athari - 14.5.2013, 13:20

КО. Надо смотреть исходы - какие буферы создаются.