Anyone kind enough point out precisely the definitive advantage differences among template, inline function/procedure, and macros ?
My feeling is that you have asked a lot of beginner questions in the last weeks? Or did I confuse your user name? Unfortunately I have not your valid email address or other contact data to sent you a personal note, but when you are able to read some simple English and are interested in learning some Nim, I would recommend you to read my book. I have recently run the languagetool app over it, so it now has hundreds of additional commas, and fewer grammar errors. Well there had been rumors that someone other had start to write a really great Nim book, which will not generate depressions -- but I think for that one you have to wait a bit still.
Also the documentation:
In regards to the question, here is an attempt at an explanation from what I understand. Please correct me if I'm wrong:
With the risk of being over-simplistic, templates can be seen as "copy-pasting" (substituting) the code in the body of the template to wherever it was called, whereas a procedure/function will have to be called and a value be returned. Calling and returning a value has some inherit overhead and that's where templates and inline-ing can help.
If I've understood inline-ing somewhat, it is basically that the compiler decides whether the function should be called as a function or in a way that is no too different from a template. I.e. the compiler decides whether the function's body should be "copied" into wherever it was called or called as a normal function. Functions can be inlined whether the {.inline.} pragma is present or not if the compiler finds potential for optimization.
Macros, finally, can generate new Nim-code during compilation at your will and change how the internal representation of the code you've written actually gets presented to the compiler. Macros have a very different use-case than normal functions and I recommend you read more about them if this sounds interesting.
Whether you explicitly should {.inline.} your functions or not is up to you, but I recommend to measure and profile your code and see if it makes a difference.
I agree with all Araq said and I know he knows all that follows, but I would add for the more casual observer that Nim's {.inline.} simply generates the definition in the same C module and adds a C inline and may not do what one thinks. The C compiler is allowed to ignore that qualification or use it only as a "suggestion" to simply "tilt the score" of whether to inline the assembly definition or not.
So, {.inline.} may do absolutely nothing -- if that makes it psychologically easier for you to not worry about the Nim directive. :-) In fact, without specifying the backend (gcc/clang/Visual C/etc.) and its version and its other command line options, you don't really know what gets inlined at the assembly level. Nim's {.inline.} just makes it easier, not actual. In this age of Link-Time Optimization (LTO), compiles can inline across translation units. This means that things can be also inlined without {.inline.}. nim c -d:lto can maybe activate this.
So, basically in the 2020s, {.inline.} is neither necessary nor sufficient to get its suggested effect. In the noughties (2000-2009) when Nim began this was less true (in both directions). Backend C/C++ compilers have become tricky to control in the modern era. gcc --help=parms|less to see hundreds of optimization parameters under command-line control.
Because of such complexities and those Araq alludes to, backends can (usually) do better with profile guided optimization (PGO) steering inlining decisions. These optimization modes are available to Nim and can sometimes get you a 2X speed boost with Nim-generated C code, but even improvement at all is hardly guaranteed.
I would be remiss to close without emphasizing that I very much agree that @mardiyah or similar people are better advised to learn/use profilers, better algorithms, more memory re-use, SIMD | thread parallelism (or the libraries of those who already know all such) before even worrying about PGO, never mind {.inline.}.