PHP: func_get_args performance?

Question

I'm about to use func_get_args for reading additional arguments of a function call.

How does this affect the performance? Should I rather use an array for passing additional arguments instead of reading them with the function above?

Answer 1

I don't think your performance will be noticeably different. It really comes down to preference. So..."Whatever floats your boat"

:D

Answer 2

Unless you are using it in mass quantities, no single function will make that much difference. You could always check how long it takes to call by using microtime() before and after the call, but I don't think you'll find anything interesting.

Go ahead and use it if you'd like.

I'd be more worried about making sure other programmers understand how the function works and knowing that they can pass any number of arguments to the function.

Answer 3

There are only those 2 possibilities, as far as I know. func_get_args is from my pov the more clean way. I use this snippet with a parser (func_parameter) heavily to get an extra flexibility. There is just a small performance reduction. Probably not noteable.

It is like the question for performance between double-quote and and single-quote. If you start thinking about it, you should rethink about PHP is the right decision in case of performance.

    $parameter = func_get_args();
    $parameter = $this->func_parameter("key,data,dispense=",$parameter);
    extract($parameter);

Non the less, PHP is fun to write. ;-) I like.

Answer 4

Should I rather use an array for passing additional arguments instead of reading them with the function above?

Yes, but more for a reason of clarity and code correctness, not so much performance. Example:

function foo($a) { }
foo(); // Warning: Missing argument 1 for foo()

function foo() { list($a) = func_get_args(); }
foo(); //no error

Also, when you see foo($a) you know immediately what to pass.

The only reason to use func_get_args is when you want a function with an arbitrary number of arguments (printf-like).