Показать сообщение отдельно
Старый 19.01.2017, 20:35   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от 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 будет высокой. Думал что он остался на неуправляемом коде. (Хотя как показал Майкл в статье, скорость бывает разной и в нашем случае видимо скорости вызова неуправляемого кода достаточна для быстрой работы)
За это сообщение автора поблагодарили: ax_mct (10).