# Testing whether an argument is PRESENT is very fast **URL:** \ **Category:** Uncategorized\ **Created:** [January 8, 2022, 2:43pm UTC](https://fortran-lang.discourse.group/t/testing-whether-an-argument-is-present-is-very-fast/2544 "2022-01-08T14:43:55Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [January 9, 2022, 1:13am UTC](https://fortran-lang.discourse.group/t/testing-whether-an-argument-is-present-is-very-fast/2544/7 "2022-01-09T01:13:17Z")
> [@ivanpribec](#): > > … Can you try compiling the procedure with optional arguments and main program in separate compilation units, and linking the objects separately (with and without link time optimization)? I really don’t think much of any meaningful insights can be gained from the kinds of micro tests like in the original post here. In actual practice, the technical community who get enamored by the `OPTIONAL` argument feature and who write code for engineering and scientific applications tend to create subroutines “from hell” with two or more optional dummy arguments, often much higher in number. Like the one in this [**thread**](https://fortran-lang.discourse.group/t/an-unallocated-variable-passed-as-an-argument-is-not-present/1724/10), albeit a made-up example in Modern Fortran Explained (8th Edition incorporating 2018). The challenge then ain’t the immeasurably small cost with the `PRESENT` intrinsic, rather the entire edifice of extremely convoluted program logic and workflow that accompanies the handling of optional parameters and corresponding program data that then leads not only to certain run-time cost but also an unbearably larger one with code readability and program maintenance and support. --- _[View the full topic](https://fortran-lang.discourse.group/t/testing-whether-an-argument-is-present-is-very-fast/2544)._