.NET CLR vs X++

[Logger]

Привет всем.

Интересно, кто-нить пробовал замерять насколько быстрее исполняется clr код по сравнению с X++

Вопрос возник по прочтении этого блога :
daxmusings: X++ in the .NET CLR : Life in the Fast Lane

[lvan]

какой код?

логичнее было бы замерить разноску заказа в ax2009 и ax2012
наверняка в маркетинговых материалах на партнерсорсе есть какая-то инфа об ускорении этого или подобного процесса

[shogel]

Цитата:

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

логичнее было бы замерить разноску заказа в ax2009 и ax2012
наверняка в маркетинговых материалах на партнерсорсе есть какая-то инфа об ускорении этого или подобного процесса

Разноску заказа в DAX2012 очень сильно перепахали, так что сравнение будет не объективным. Самый простой вариант - взять этот метод:

PurchTable::initFromVendTableIL

и запустить его в среде X++, а потом в .NET. У меня выполнение кода в .NET в среднем дает прирост производительности на 10-15%

[Logger]

А возможно заставить 2012-ю делать разноску заказа не используя IL ?
Это было бы самым объективным сравнением.
Хотя наверно скорость несильно бы отличалась.
Все равно в разноске главное - время ожидания БД.

Надо какую-то другую длительную операцию подобрать. Там где БД меньше дергается.

[lvan]

я думаю, что если постараться, то можно найти такой код, который будет в 10 раз быстрее работать? но зачем?

[belugin]

Цитата:

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

я думаю, что если постараться, то можно найти такой код, который будет в 10 раз быстрее работать? но зачем?

Например, чтобы понимать примерно, насколько ускорится нужный код. То есть, если мы знаем, что в нужном коде быстродействие жрет 50% X++ и 50% SQL и копиляция в CLR даст примерно 70 кратный прирост производительности X++ как такогого, то результирующее ускорение будет примерно в 2 раза.

=== ниже информация неофициальная и, возможно, ложная ===

Насколько я помню тупой код типа цикл с присваиванием переменной укоряется в 70 раз.

Еще есть разные факторы - в .NET используется недетерминированный сборщик мусора, а в X++ детерминированный (он должен убрать мусор сразу как только нет на него ссылок). В результе X++ при каждом присваивании считает циклы - что дает квадратичный, кажется, прирост времени выполнения при присваиваниях полей классов с развесистым графом объектов, например, в разноске больших журналов.

В-общем, попробуйте отпрофилировать TraceParserом ваши задачи.

Еще следует учесть что включение HotSwapping помещает ваши сборки в отдельный домен, что дает некоторое увеличение времени вызова между вашим кодом и ax32serv

[Logger]

Цитата:

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

В результе X++ при каждом присваивании считает циклы - что дает квадратичный, кажется, прирост времени выполнения при присваиваниях полей классов с развесистым графом объектов, например, в разноске больших журналов.

Максим, а можно эту тему поподробнее раскрыть ?
Не совсем понятно какие операции приводят к такому сканированию. И как этого избегать в своих разработках.

[AndyD]

Цитата:

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

Максим, а можно эту тему поподробнее раскрыть ?

Поддерживаю.
Не совсем понятно, что имеется в виду.

[Logger]

Цитата:

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

Еще есть разные факторы - в .NET используется недетерминированный сборщик мусора, а в X++ детерминированный (он должен убрать мусор сразу как только нет на него ссылок). В результе X++ при каждом присваивании считает циклы - что дает квадратичный, кажется, прирост времени выполнения при присваиваниях полей классов с развесистым графом объектов, например, в разноске больших журналов.

Хм, получается что если мы пишем метод для передачи параметра-ссылки на объект, то в нем лучше делать минимум присваиваний.
Т.е., например, такой метод :
\Classes\InventUpd_Financial\parmLedgerVoucher

LedgerVoucher parmLedgerVoucher(LedgerVoucher _ledgerVoucher = ledgerVoucher)
{
    ;
    ledgerVoucher = _ledgerVoucher;
    return ledgerVoucher;
}

на чтение работал бы быстрее при такой реализации (меньше присваиваний) :

LedgerVoucher parmLedgerVoucher(LedgerVoucher _ledgerVoucher = null)
{
    ;
    if ( !prmIsDefault(_ledgerVoucher) )
    {
        ledgerVoucher = _ledgerVoucher;
    }

    return ledgerVoucher;
}

[_scorp_]

Цитата:

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

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

Не забывайте, что в X++ нет inline-функций, следовательно в Вашем примере появятся накладные расходы на вызов функций.

[Logger]

Цитата:

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

Не забывайте, что в X++ нет inline-функций, следовательно в Вашем примере появятся накладные расходы на вызов функций.

Это копейки по времени исполнения. Можно забить.

[lev]

Цитата:

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

...

на чтение работал бы быстрее при такой реализации (меньше присваиваний) :

LedgerVoucher parmLedgerVoucher(LedgerVoucher _ledgerVoucher = null)
{
    ;
    if ( !prmIsDefault(_ledgerVoucher) )
    {
        ledgerVoucher = _ledgerVoucher;
    }

    return ledgerVoucher;
}

интересно а функция prmIsDefault() всегда корректно отрабатывает в AX2012 и 2009... А то помнится в трешке она почему то иногда некорректно отрабатывала (параметр передан и не равен значению по умолчанию, а функция возвращает true)!
Подробностей уже не помню, но точно помню, что закономерности в сбоях этой функции так и не нашел...

[belugin]

Цитата:

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

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

Не факт, что присваивание, которое не изменяет значение приводит к пересчету циклов
Не факт, что присваивани, которое не изменяет полей объектов приводит к пересчету циклов.

Попробуйте провести эксперимент.

[Logger]

Цитата:

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

Не факт, что присваивание, которое не изменяет значение приводит к пересчету циклов
Не факт, что присваивани, которое не изменяет полей объектов приводит к пересчету циклов.

Попробуйте провести эксперимент.

Попробую. Пока правда нет понимания как лучше построить тест.
Когда я оптимизировал разноску закупки с 1000 строк и 8000 записей в логе корреспонденции, то выполнение этого метода
\Classes\InventUpd_Financial\parmLedgerVoucher

Стабильно длилось примерно 4,5 миллисекунды.
Мелочь, конечно, можно и внимания не обращать, но для простого копирования ссылки все же многовато.

[Logger]

В принципе незачем.
Просто интерес.

[Logger]

Кстати, по поводу сборки мусора.
Интересно как это все в 2012-й работает. Он теперь там всегда недетерминированный ? Или есть отдельно куча .Net и отдельно X++ и обрабатываются они по разному ?

Думаю это достаточно важный вопрос, так как в X++ в некоторых местах код явно закладывается на то что сразу после присваивания :

Object = null;

объект Object убивается и ресурсы (например файл на диске если Object - это файл) высвобождаются для работы. А теперь это может быть и не так.

[plumbum]

Цитата:

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

Кстати, по поводу сборки мусора.
Интересно как это все в 2012-й работает. Он теперь там всегда недетерминированный ? Или есть отдельно куча .Net и отдельно X++ и обрабатываются они по разному ?

Кучи у них разные, как и раньше:

X++, C# Comparison: Object Oriented Programming [AX 2012]

Цитата:

In C#, the System.GC.Collect method in the .NET Framework can be called to start the garbage collector. There is no similar function in X++ because X++ uses a deterministic garbage collector.

Собственно Х++ так и не стал Managed языком, для этого и ввели возможность перекомпилировать Х++ код в .NET код.

[Logger]

Цитата:

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

Собственно Х++ так и не стал Managed языком...

Что же ему не хватает ?

[plumbum]

Класический пример плохой работы сборщика мусора в АХ, это перекрестные ссылки между деревом и элементами дерева:

Dynamics AX Performance issue. Cross object references drawbacks


Подробная информация о сборке мусора в X++ и .NET тут

[plumbum]

мне кажется просто не хотели переносить фокус на переработку IDE.
Само ядро AX интерпритирует код Х++ в P код, который по своей сути является чем-то вроде MSIL, но "не то"