AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 18.05.2013, 01:14   #1  
Blog bot is offline
Blog bot
Участник
 
25,475 / 846 (79) +++++++
Регистрация: 28.10.2006
axtools: Worth knowing when you leave part of your application broken
Источник: http://blogs.msdn.com/b/axtools/arch...on-broken.aspx
==============

We've seen a number of instances where part of the application was left in broken state "because we don't use that part anyway". While we understand the sentiment behind this statement and attempt to accommodate the behavior through e.g. the suppression list for IL generation, there's something you need to understand when you do this: your compile time will suffer - sometimes quite significantly. So why is that? Let's examine how the X++ compiler and metadata validation works:

AX doesn't employ a dependency driven build system, but rather an algorithm that is driven by the amount of errors it encounters in each compile pass through the AOT. This strategy requires a minimum of two passes - exactly two in the best case, and more if there are "unfortunate" dependencies as these might turn out as errors in the second pass as dependencies are yet to be compiled. The third pass will typically take care of this subset. However, the compile time is proportional to the size of each pass and the elements processed. If an element fails to compile successfully in a pass, it is added to the next pass and thus increases the effort in that next pass. Compilation ends (success or fail) when the last pass didn't provide further progress on resolving the pending errors.

So you see how that gets effected by broken application? You've effectively added dead weight to each pass after the second and depending on what you've left broken, it might entail quite significant increase in compile time. E.g. forms are quite intricate to compile and verify, so are tables and classes, so if you leave a significant number of these broken, your compile time might suffer quite significantly.

Bottom line: leaving part of your application broken is not just a risk from an execution perspective. It also negatively effects the turn-around time when you need to compile.






Источник: http://blogs.msdn.com/b/axtools/arch...on-broken.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
workflowax: Demo leave application workflow template Blog bot DAX Blogs 0 15.11.2010 19:11
axtools: Navigating the AX Application Explorer in Visual Studio Blog bot DAX Blogs 9 05.04.2010 12:48
axtools: AX Application Explorer in Visual Studio Blog bot DAX Blogs 9 24.03.2010 15:23
Microsoft Dynamics CRM Team Blog: List Web Part for Microsoft Dynamics CRM 4.0 Deployment Scenarios Blog bot Dynamics CRM: Blogs 0 30.01.2009 22:05
Microsoft Dynamics CRM Team Blog: List Web Part for Microsoft Dynamics CRM 4.0: Understanding Connections Blog bot Dynamics CRM: Blogs 0 20.01.2009 02:07
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:34.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.