Partilhar via

Worth knowing when you leave part of your application broken

  • Artigo

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.

Comments

  • Anonymous
    May 20, 2013
    With the risk of sounding to demanding; could you add some visual presentation of the flow of how the AOT is compiled and how these errors will trigger new compilation passes? :-)
  • Anonymous
    June 11, 2013
    @skaue - hope the new blog entry helps.