Should you avoid adding unecessary stack frames?

Question

I have been working with laravel (PHP) recently, and there is an option when using their fluent ORM to define where clauses using closures. This gives us two, functionally equivalent, ways to specify a where clause that should only be added in certain cases:

Example 1

    $query = App::make('Vendor_Orders')->
        where(function($query) use ($admin) {
            if (!$admin) {
                $query->where('vendor_id', '=', $this->id);
            }
        })->
        get();

Example 2

    $query = App::make('Vendor_Orders');
    if (!$admin) {
        $query->where('vendor_id', '=', $this->id);
    }
    $query = $query->get();

As you can see, one of these is using a closure (and maintaining the "fluent-ness"), while the other avoids it. My instinct is to prefer the second, because using an anonymous function like that is adding an extra stack frame, which I would expect to make the program less efficient (possibly a holdover from my time working with C). On the other hand, my colleague (whose first language was PHP) prefers the first example, because it avoids the use of a second assignment operator, and he doesn't see anything wrong with piling up extra function calls.

This started me wondering - how much effect does that extra stack frame really have, in a modern system? Does it make any practical difference if one uses a function call instead of an if statement?

I'm not looking for subjective which-do-you-prefer answers, I'm asking for some sort of facts regarding the impact of unnecessary jumps - particularly to anonymous functions - in modern, interpreted languages (e.g. PHP, Java, etc.). Possibly also some notes on how this differs from old-school compiled languages.

Answer 1

Interesting question, but I really think you are approaching this at the wrong level of abstraction. You are writing a web application, probably it will be maintained by yourself and colleagues who will need to make changes to your code. Your first cost to consider is your own productivity. Is one version of the code clearer than the other? Does one version fit better with your coding conventions and style? Is one version easier to test and refactor?

Once you have considered all of that, then thing about whether performance is really an issue. This is difficult for web applications, because the overall performance of an app can be influenced by many things which are outside of your control. However, if you can stress test this code then that would be a good idea. But don't just performance test this snippet, work through a whole use case. Then use a profiler to see whether using more or fewer closures really has an overall effect on your code.

In general though, I would suggest that this sort of micro-managing of performance will lead you down an unproductive rabbit hole. Not only is it difficult (and time consuming) to figure out whether your coding style is having a real effect on the end-user, it may be that performance can be improved by changing or updating or reconfiguring your PHP runtime.

There are SO MANY variables in performance benchmarking, better to deal with readability and maintenance issues first.

Answer 2

The additional invocation is essentially trivial. Avoiding doing something better to avoid a function call is a premature micro-optimization. Write first for readability and maintainability. Once the program is written, you can benchmark performance, and make adjustments from there (and I would strongly suspect your performance bottleneck is not the stack).

Part of the reason this is so trivial is that code calls functions a lot, therefore compilers and interpreters have highly optimized the internals of calling a function. It is better to make the code more readable and not worry so much about the stack.

(I'd still say the second is better, but because it is more readable to me.)