Auto Optimization Tool

[moderator1983]

I would always like to see an Auto Optimization Tool (AOT), that will actually suggests and corrects not just Rube Goldberg Code but also unnecessary/unused codes. I understand, based on continuous advancements in the LabVIEW compiler, compiled code generated from the VI are optimized to great extent... but we like to see if in the source code itself, some sort of optimization can be done so that a developer (specially learners like me) also gets to know that, in what different ways code can be optimize or what section of their code can be removed without affecting the functionality.

Now after I select AOT, similar to BDCT, it should make the code optimized. There should also be an available option, just to list, wherever this tool feels correction is required and let developer to take a call whether modify it or leave as it is.

Few examples what AOT should be capable of:

1. Remove Coercion Dots:

2. Remove Unnecessary Constants:

3. Remove Unnecessary Code:

well there is no end of types of 'unnecessary codes'... 

Any other suggestion you want to add, is most welcome... 

[Intaris]

I think the compiler optimises a lot of this away anyway.  I don't want LabVIEW changing my source code.

[moderator1983]

@ Intaris.

Yeah, even I don't want, everytime AOT should change my code... So one need to select 'Only Show Suggestions' and AOT will just do nothing except showing where all changes can be done in order to make the existing code more optimized...!!

[altenbach]

Well, all you need is add a few more tests to the "VI analyzer" we already have. 🙂

[AristosQueue (NI)]

This request is covered by VI Analyzer and the LV compiler itself. The compiler will optimize as much as it can within the syntax given (like all the Boolean simplification *provided you have debugging turned off*). For the others, VI Anlyzer has tests for many of the things you mention (such as the *forked* wire with multiple coercion dots... the single coercion dot as shown in your first picture is not a performance problem and is exactly equivalent to the coercion bullet node). You are free to add additional tests to VI Analyzer if you have other patterns that you commonly observe and want to correct. NI adds more of these regularly.

[altenbach]

Also, the correct way to deal with case #1 is to change the representation of the indicator to U8, or simply configure it to auto adapt to the source.

[moderator1983]

Locating coercion dot, with the help of VI analyzer toolkit... that's possible but when it comes to remove the coercion dot, that's beyond what VI analyzer toolkit offers...

Also regarding other two points (Remove Unnecessary Constants & Remove Unnecessary Code), that is not at all possible using VI analyzer...!!

So my request is much beyond what VI analyzer offers...!!

[Intaris]

You mention you're a learner.

LabVIEW doing these things for you will not help you learn.  It's rewarding you for doing things inefficiently.  Your goal should be to program correctly without such help.  If it's done automatically, you might never even find out that what you were doing was incorrect.

I find the VI Analyzer help with manual correction to be sufficient.

[AristosQueue (NI)]

> Also regarding other two points (Remove Unnecessary Constants & 

> Remove Unnecessary Code), that is not at all possible using VI analyzer...!!

LabVIEW *does* do those things, already, today. When the code is compiled, those sorts of things get optimized away (when debugging is turned off). You don't pay a performance penalty for those because the optimizer handles it.

[ouadji]

@ Intaris : "I don't want LabVIEW changing my source code."

+1

[Dragis]

I would support this idea if it was more like other code cleanup tools that suggest safe modifications like removal of unreachable code, invariant code motion, etc. and then provide a simple shortcut to have LabVIEW make the change. The compiler should be able to clean the code up internally, but many changes could also make the source code more readable and maintainable.