It would be very beneficial if there was a tool that could help developers create better code. The advances in the in LabVIEW 2010 with multi-pass compilation and use of Dataflow Intermediate Representation (DFIR) it could provide feedback to the developer on how to write better code. As time goes on we all think we write perfect code and it would be beneficial to have the compiler remind us that there is a better way. As the code is compiled, it could identify modules that are written inefficiently and could use a rewrite. By providing a simple color coded list of VIs compiled, this could provide quick feedback on the state of your current code. Red would indicate heavy optimization, yellow would indicate some optimization, and green would be the code is good. Over time, engineers would learn how to write better code based on compiler feedback.
VI Name |
% Optimized |
subSigGeneratorBlock.vi |
64 |
Nearest Frequency for Block.vi |
62 |
Nearest Freq in Int Cycles.vi |
55 |
subInternalTiming.vi |
55 |
NI_MABase.lvlib |
41 |
NI_AALBase.lvlib |
38 |
subShouldUseDefSigName.vi |
34 |
sub2ShouldUseDefSigName.vi |
30 |
Clear Errors.vi |
25 |
subGetSignalName.vi |
22 |
Merge Errors.vi |
18 |
ex_GenAddAttribs.vi |
14 |
Timestamp Subtract.vi |
10 |
DU64_U32SubtractWithBorrow.vi |
9 |
I128 Timestamp.ctl |
4 |
ex_SetExpAttribsAndT0.vi |
0 |
Timestamp Add.vi |
0 |
DU64_U32AddWithOverflow.vi |
0 |
ex_SetAllExpressAttribs.vi |
0 |
ex_WaveformAttribs.ctl |
0 |
ex_WaveformAttribsPlus.ctl |
0 |
Waveform Array To Dynamic.vi |
0 |
ex_CorrectErrorChain.vi |
0 |
Other advances would be to click on the VI in the list and be presented with a list or graphical representation on the changes that were made to the source VI during optimization. This would be similar to the diagrams shown in the DFIR Decompositions in the NI LabVIEW Compiler: Under the Hood document on NI’s web site. Options for the future could be suggesting documents for better code development, training, or the level of LabVIEW (Novice, CLAD, CLD, or CLA) the code is written.
It seems that useful information could be feed back to the developer based on the compile process. This can be implemented in many ways and I have provided a few suggestions. As developers we should always look for ways to create better code and not depend on the compiler to make our code better.
Reference Document: NI LabVIEW Compiler: Under the Hood
http://zone.ni.com/devzone/cda/tut/p/id/11472
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.