Помогите найти: Сравнение производительности различных операндов при конкатенации строк

[ax_mct]

В .NET на больших массивах самое эффективное использовать StringBuilder.
Вполне логично предположить что TextBuffer его полный аналог, а с компиляцией в IL возможно что по сути тот же IL код. То есть рекомендации ниже должны подходить и для TextBuffer.

Цитата:

Определённо используйте StringBuilder, когда вы конкатенируете строки в нетривиальном цикле, и особенно, когда вы не знаете (на момент компиляции), сколько именно итераций будет произведено. К примеру, чтение содержимого текстового файла путём считывания по одному символу внутри одной итерации в цикле, и конкатенация этого символа через оператор += предположительно «убьёт» ваше приложение в плане производительности.

Определённо используйте оператор +=, если вы можете указать все необходимые для конкатенации строки в одном утверждении. Если вам нужно конкатенировать массив строк, используйте явный вызов String.Concat, а если между этими строками нужен разделитель — используйте String.Join.

Статья 2013 года, но StringBuilder вполне себе живой и сейчас.
https://habrahabr.ru/post/166701/

P.S. Кстати интересно стоимость вызова и использования System.Text.StringBuilder вместо TextBuffer. Если это ничего не стоит когда в IL, то может лучше сразу .NET использовать?

[Logger]

Цитата:

Сообщение от ax_mct

Если это ничего не стоит когда в IL, то может лучше сразу .NET использовать?

Мне тоже кажется что так лучше было бы. Я вообще думал что TextBuffer не покажет таких цифр производительности. Думал он вообще реализован как не IL объект и будут накладные расходы на вызов между IL кодом и обычным неуправляемым кодом.

[ax_mct]

Цитата:

Сообщение от Logger

Мне тоже кажется что так лучше было бы. Я вообще думал что TextBuffer не покажет таких цифр производительности. Думал он вообще реализован как не IL объект и будут накладные расходы на вызов между IL кодом и обычным неуправляемым кодом.

Кстати я абсолютно без понятия что там с TextBuffer случается в IL.
Это хороший пойнт насчет того что что-то может и не переводиться в IL. Ни в чем нельзя быть уверенным

Надо бы порыть насчет того что остается P-кодом при полной компиляции в CIL.
И понять в этом контексте стоимость использования .NET обьектов в X++ коде.

[Logger]

Цитата:

Сообщение от ax_mct

Кстати я абсолютно без понятия что там с TextBuffer случается в IL.
Это хороший пойнт насчет того что что-то может и не переводиться в IL. Ни в чем нельзя быть уверенным

Да вот же mfp явно обо всем рассказал применительно к 2012 R3 :
https://blogs.msdn.microsoft.com/mfp...-to-the-metal/

А в комментариях в ответ на претензию

Цитата:

The T-Shirt lies. There is no such thing as fast X++ code. Please make X++ a full blown CLR language ASAP. Otherwise we are all doomed (a partner).

раскрыл что случается с классами ядра:

Цитата:

Thanks for the feedback alibertism, Your comment nicely demonstrates the core problem this post is trying to qualify. In my examples above all X++ code is running in CLR – the problem is not with the language.

Even if X++ was a full blown CLR language you would still face these problems. What we need to fix is not "just" the language and compiler – but all the libraries you are using when writing X++ code. In AX 2012 the majority of these are written in C++. To avoid the interop overhead we need to replace these with CLR implementations. This includes everything under System Documentation in the AOT, i.e >100 built-in functions, > 500 classes and the entire data access stack.

Solving all this – and more is in the works for the next major release of AX – code named "Rainier".

Правда так и осталось тайной, как же обстоят дела с 7.0 Переписали они ядро на .Net или пока оставили как было.

Именно поэтому я и сомневался в том, что скорость вызова TextBuffer будет высокой. Думал что он остался на неуправляемом коде. (Хотя как показал Майкл в статье, скорость бывает разной и в нашем случае видимо скорости вызова неуправляемого кода достаточна для быстрой работы)