AX2012 X++ Comparison tool works slowly?

[DSPIC]

A useful hint how to improve performance of X++ comparison tool for AX2012: Just try to turn-on the parameter “Execute business logic in CIL” in your profile, it’ll compare elements extra fast.
It’s a common case when developers keep this option OFF that pushes Comparison tool to be executed in classic X++ mode instead of CIL.

Some details:

\Classes\SysCompareText\run
Вложение 11024

[gl00mie]

см. также mfp: The compare tool–and running X++ code as IL

[Logger]

В 2012-й не исследовал, но в 2009-й еще могло тормозить на больших объектах которые лежат на куче слоев. Например, есть SalesTable табличка с кучей кастомизаций и большим числом методов. Аксапта при формировании комбобоксов для сравнения грузит в память treenode из каждого слоя (примерно 5 штук) и из каждого old слоя - еще 5 штук. И зачем-то делает это дважды. На этом может теряться секунд 20-40 - зависит от нагрузки на сервера. Можно это место оптимизировать - подгружая в память treenode объекта со слоя не сразу, а только когда (и если) он вообще понадобится. Но это модификация не на пару строк кода.

[alex55]

Цитата:

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

A useful hint how to improve performance of X++ comparison tool for AX2012: Just try to turn-on the parameter “Execute business logic in CIL” in your profile, it’ll compare elements extra fast.
It’s a common case when developers keep this option OFF that pushes Comparison tool to be executed in classic X++ mode instead of CIL.

Как вариант, вместо включения галки просто для класса SysCompareText от проверки параметра отвязаться, поставив выполнение в CIL принудительно (если речь про приложение для разработки во всяком случае). Вроде этому ничего особо не препятствует?

[DSPIC]

Цитата:

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

Как вариант, вместо включения галки просто для класса SysCompareText от проверки параметра отвязаться, поставив выполнение в CIL принудительно (если речь про приложение для разработки во всяком случае). Вроде этому ничего особо не препятствует?

не препятствует. Главное чтобы CIL был собран в области компаратора.

[Link]

Цитата:

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

Как вариант, вместо включения галки просто для класса SysCompareText от проверки параметра отвязаться, поставив выполнение в CIL принудительно (если речь про приложение для разработки во всяком случае). Вроде этому ничего особо не препятствует?

Плохая идея - без работающего CIL не будет работать. У меня чекбокс на форме которая выставляет глобальную переменную, которая в свою очередь игнорирует настройки пользователя для сравнения. Проблема в том, что когда нужно много и долго сравнивать (после апгрейдов и хотфиксов) CIL то как раз и не рабочий. Так что всё как обычно - красиво в теории и бесполезно на практике У меня всё руки не доходят прикрутить сравнение с помощью VS.

[alex55]

Цитата:

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

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

Могли бы пояснить что имеется в виду? Перед тем как что-то сравнить нужно сначала это что-то откомпилить в CIL, чтобы сравнение работало с включенной галкой выполнять в CIL?

[alex55]

Цитата:

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

см. также mfp: The compare tool–and running X++ code as IL

Собственно там в комментах как раз ссылка на статью с примером реализации исключения компаратора из проверки глобального параметра выполнять в CIL. Только ссылка битая, вот нормальная: Do yourself a favor, and make this change on your Dev system - https://community.dynamics.com/ax/b/...our-dev-system

[Link]

Цитата:

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

Могли бы пояснить что имеется в виду? Перед тем как что-то сравнить нужно сначала это что-то откомпилить в CIL, чтобы сравнение работало с включенной галкой выполнять в CIL?

Я про то, что если вы захардкодите выполнение в CIL а он у вас не рабочий, к примеру после установки хотфикса - при попытке сравнить будет вылетать ошибка и придется убирать код, что бы заработало.

[alex55]

Цитата:

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

Я про то, что если вы захардкодите выполнение в CIL а он у вас не рабочий, к примеру после установки хотфикса - при попытке сравнить будет вылетать ошибка и придется убирать код, что бы заработало.

Вообще я про хардкод ничего не писал. Принудительное выполнение можно и через новый параметр реализовать, идея была в том чтобы от глобального параметра отвязаться. Но спасибо за полезное замечание.

Единственно мне пока не совсем понятно в какой именно части должен быть нерабочим CIL, чтобы перестало работать сравнение через CIL: в любой или только в части данного класса и объектах которые он использует? Мне казалось что второе верно, но для меня это вообще очень редкий кейс.

[Link]

Цитата:

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

Вообще я про хардкод ничего не писал. Принудительное выполнение можно и через новый параметр реализовать, идея была в том чтобы от глобального параметра отвязаться. Но спасибо за полезное замечание.

Единственно мне пока не совсем понятно в какой именно части должен быть нерабочим CIL, чтобы перестало работать сравнение через CIL: в любой или только в части данного класса и объектах которые он использует? Мне казалось что второе верно, но для меня это вообще очень редкий кейс.

У меня принудительно ассоциируется с кодом, а параметр с гибким подходом.

Ну например у меня недавно было после восстановления из бэкапа и установки хотфиксов. Сравнение не работало пока не переключил на xpp. Поэтому я бы не советовал подход автора Do yourself a favor, and make this change on your Dev system, а делал бы сразу через отдельный параметр. Надеюсь теперь все точки расставил...

[alex55]

Цитата:

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

У меня принудительно ассоциируется с кодом, а параметр с гибким подходом.

Ну например у меня недавно было после восстановления из бэкапа и установки хотфиксов. Сравнение не работало пока не переключил на xpp. Поэтому я бы не советовал подход автора Do yourself a favor, and make this change on your Dev system, а делал бы сразу через отдельный параметр. Надеюсь теперь все точки расставил...

Я тоже за гибкость и красоту, особенно если они покрывают 80% потребностей за 20% усилий. А если голое приложение раз в неделю персонально для себя из репозитория разворачиваешь и свои девелоперские примочки накатываешь на системные объекты (желательно со сравнением), то и хардкод более чем 80% потребностей легко покроет. Так что реализация приведенная по ссылке выше вполне имеет право на жизнь имхо