Enable inline subvi property.

[LV_COder]

Is it good to enable the subvi inline property to achieve better run time performance of the VI.

Is this property really impact the run time performance of the VI?

[altenbach]

Typically it makes no difference unless the subVI only contains relatively small amounts of code and is placed in a tight loop.

It is not a good idea to have large hierarchies of inlined code inside inlined code because it requires significantly more effort to compile. (The cyclomatic complexity might go through the roof because the entire inlined code hierarchy is flattened to the caller diagram behind the scenes!)

[Yamaeda]

If you do a simple test VI you'll see the cost of a function call is a few ns, in most cases this is negligable, but in a small VI it could be bigger than the actual code execution.

So yes, it impacts run time performance, if it's good depends on the circumstances.

/Y

[Hooovahh]

Yes as others have said it is usually good for functions that are small, and called often (or can be called often).  Good examples are things you might find in a small resuse library, like many OpenG functions (which aren't inlined BTW).  The benefit you see will often be very small, and the downside is debugging will be turned off, meaning no probes/breakpoints, and it is reentrant so seeing the front panel controls will be difficult.  Which is also a good reason to apply inlineing only to small reuse functions that have been tested, and don't expect debugging to be needed.

[billko]

---

@LV_COder wrote:

Is it good to enable the subvi inline property to achieve better run time performance of the VI.

Is this property really impact the run time performance of the VI?

---

The funny thing is, if you can't answer that question yourself, you probably don't need to worry about it.  🙂

[wiebe@CARYA · Accepted solution]

---

Hemant_LV wrote:

Is this property really impact the run time performance of the VI?

---

Yes. It saves a call (with I doubt is ever significant) but more importantly, it might prevent data copies.

---

@LV_COder wrote:

Is it good to enable the subvi inline property to achieve better run time performance of the VI. 

---

Optimise when needed, not because you can.

Obviously, it's good to make your code keeping efficiency in mind. But inlining comes at a cost. It complicates debugging, slows down compilation, increases executable size, and can cause some weird updating problems in recursive class hierarchies.

A "mild version" of inlining is re-entrancy. This is something completely different, but when the VI takes some time, it might increase execution when parallel callers access the VI. It's also a bit harder to debug then a normal VI, but not as hard as an inlined VI. So when inlining is not recommended (when the VI is not trivial), re-entrancy might work.