Does recursive function parameters order affect performance - performance

Question

Consider a frequently called recursive function having some parameters which do vary a lot among executions, and some which don't, representing some kind of a context information. For example, a tree traversal might look like this
private void Visit(Node node, List<Node> results)
{
if (IsMatch(node)) {
results.Add(node);
}
Visit(node.Left, results);
Visit(node.Right, results);
}
...
Visit(root, new List<Node>());
Obviously results collection is created once and the same reference used throughout all traversal calls.
The question is, does it matter for performance whether the function is declared as Visit(Node, List<Node>) or Visit(List<Node>, Node)? Is there a convention for the arguments order?
The vague idea is that fixed parameters might not be pushed in or popped out of stack constantly, improving the performance, but I'm not sure how feasible would that be.
I'm primarily interested in C# or Java, but would like to hear about any language for which the order matters.
Note: sometimes I happen to have three of four parameters overall. I realize that it is possible to create a class holding a context, or an anonymous function closing the context variables, but the question is about plain recursion.

Answer 1

This is going into the deepest conjecture territory for me, since there are an explosive number of variables that could affect the outcome ranging from the calling conventions of the platform to the characteristics of the compiler.
The question is, does it matter for performance whether the function
is declared as Visit(Node, List) or Visit(List, Node)? Is
there a convention for the arguments order?
In this kind of simple example, probably the most concise answer I can give is, "no unless proven otherwise" -- "innocent until proven guilty" sort of thing. It's highly unlikely.
But there are interesting scenarios that crop up in a more complex example like this:
API_EXPORT void f1(small a, small b, small c, small d, big e);
... vs:
API_EXPORT void f2(big a, small b, small c, small d, small e);
In this case, f1 might actually be more efficient than f2 in some cases.
It's because some calling conventions, like Win x64, allow the first four arguments passed to a function to be passed directly through registers without stack spills provided that they fit into a register and make up the first four parameters of the function.
In this case, with f1, the first four small arguments might fit into registers but the fifth one (regardless of size) needs to be spilled to the stack.
With f2, the first argument might be too big to fit into a register, so it needs to be spilled into the stack along with the fifth argument, so we could end up with twice as many variables being spilled to the stack and take a small performance hit (I've never actually measured a case like this, however).
This is a rare case scenario though even if it occurs, and it was critical for me to put that API_EXPORT specifier there because, unless this function is being exported, the compiler (or linker in some cases) can do all kinds of magic and inline the function and things of that sort and obliterate the need to pass arguments in this kind of precise way defined by its ABI.
In this kind of case, it might help a little bit to have parameters sorted in ascending order from smallest types that fit in registers to biggest types that don't.
But even then, is List<Node> a big type or a small type? Can it fit into a general-purpose register, e.g.? Languages like Java and C# treat everything referring to a UDT as a reference to garbage-collected memory. That might boil down to a simple memory address which does fit into a register. I don't know what goes on here under the hood, but I would suspect the reference itself can fit into a register and is actually a small type. A big type would be like a 4x4 matrix being passed by value (as a deep copy).
Anyway, this is all case-by-case and drawing upon a lot of conjecture, but these are potential factors that might sway things one way or another in some rare scenario.
Nevertheless, for the example you cited, I'd suggest a strong "no unless proven otherwise -- highly improbable".
I realize that it is possible to create a class holding a context, or
an anonymous function closing the context variables [...].
Often languages that provide classes generate machine instructions as though there is one extra implicit parameter in a function. For example:
class Foo
{
public:
void f();
};
... might translate to something analogical to:
void f(Foo* this);
It's worth keeping that in mind when it comes to thinking about calling conventions, aliasing, and how parameters are passed through registers and stack.
... but the question is about plain recursion
Recursion probably wouldn't affect this so much except that there might come a point where the compiler might cease to inline recursive functions, e.g. after a few levels, at which point we inevitably pay the full cost required of the ABI. But otherwise it's mostly the same: a function call is a function call whether it's recursive or not and the same concerns tend to apply for both. Potentially relevant things here most likely have much more to do with compiler and platform ABI than whether or not a function is being called recursively or non-recursively.