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

[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 будет высокой. Думал что он остался на неуправляемом коде. (Хотя как показал Майкл в статье, скорость бывает разной и в нашем случае видимо скорости вызова неуправляемого кода достаточна для быстрой работы)