Optional argument impact on runtime

[leonfoks]

At the risk of discussing early over-optimization... I want to discuss the possible speed and optimization issues with having too many optional arguments.

I can't remember which class I took, but I distinctly remember someone saying that optional arguments can be a serious slowdown in large scale applications. I'm not sure if this is true so i'm asking!

Can anyone shed some light on how the compilers generally handle optional arguments? Are optional arguments determined at compile time? Or at runtime? If the latter, could there potentially be a substantial slowdown in large scale code?

Why am I bringing this up now? In the discussions of nan() and var() optional arguments are present, and i wanted to bring this up in case it is important before we move too far ahead with other modules. If we can potentially prevent a base level of slowdown due to optional arguments, that might be advantageous at this point???

Am I overthinking this?

[milancurcic]

I think it's good and important topic to discuss, if for nothing else but for our understanding as we move forward.

My understanding here is quite limited, so I hope @certik @sblionel @klausler can shed some light.

From all I can tell, presence of optional arguments at least can be resolved at compile time because there's no other way to pass an argument to a procedure other than by typing it out in the code (unlike e.g. Python). But whether compilers do that, I have no clue.

The slow-down can perhaps occur if the procedure is called from a tight, nested loop, and the procedure goes through many if-branches to find out whether the argument is present or not.

There's likely some overhead from just calling a procedure. Rule of thumb I was taught early on was to minimize calling procedures from tight nested loops.

[jvdp1]

Good point @leonfoks . I don't have the answer.

Regarding mean and var functions, the scalar mask is optional in the implementation. It could be avoided by duplicating the functions (one with no mask as argument, and one with it as argument). The interface would do the job. However, it would add ~100(?) functions to the already high number of functions.

Somewhat related to this topic, I am also wondering what is the penalty (if any) to have some many functions in an interface block. I would hope that the right function is choosen at the compile time.

[sblionel]

@jvdp1 > I am also wondering what is the penalty (if any) to have some many functions in an interface block. I would hope that the right function is choosen at the compile time.

Yes, it is.

@milancurcic The compiler can see that a called procedure has an optional argument, as the standard requires an explicit interface be visible. For intrinsic procedures, of course, the compiler has even more information and might call different routines or expand things differently depending on presence optional arguments.

The canonical implementation is that an omitted argument is passed as a zero address. This is explicit in the C interoperability text but is how it works in most compilers. Testing for omission is just testing for a zero address.