Does the size of a function affect memory performance and consumption?

Question

Does the fact that a function is higher or lower affect the performance of the application? Especially in PHP. If you need performance, it would be better to perform large or small?

And memory consumption is affected if a large function gives rise to several small functions?

Answer 1

At all times can affect performance. It depends a little on the technology used. Language, implementation. The same goes for memory consumption.

But this "can" is relative. I will avoid talk about the content of the function and stick purely to her size. But do not forget that the size concern should be more relevant to facilitate the design and understanding by programmers.

Performance

In the past, the existence of many functions hindered performance and it made sense to perform "language" functions. Today the hardware help and compilers often do optimizations that eliminate the overhead of function calls created just to keep the code more organized. Of course, the cost of calling a function is not zero and optimizations are not always possible. There are cases that optimization is possible but not feasible or at least necessary (functions that have loops nay unwound in code flat probably will not suffer the optimization of inline which replaces the call with its own code). But it is also certain that there are not so many cases where this is really relevant.

On the other hand, small functions can facilitate better utilization of the processor’s code cache (this varies from processor to processor) and in some cases can positively affect performance. Again, it’s not usually very relevant in most cases.

This varies according to implementation and in dynamic languages is usually even less relevant.

This concern can already be considered a micro-optimization in any language. But it may not be in specific cases. In PHP it is probably one of the slowest languages for function calls. If someone really needs performance, why would they choose PHP? PHP is great for solving various problems, has its virtues but among them is not speed. PHP is one of the languages mainstream slower than there are, the problem is not only in calling the functions.

Optimizations that involve the right choice of algorithms and data structures are important. In some cases knowing some implementation flaw and trying to circumvent may be an acceptable micro-optimization, but breaking a function into small parts or making a "linguistics" will hardly bring any relevant result in PHP. Probably not worth testing to see what happens. But if someone has data that shows this, they will not cease to be useful at least to make sure that nothing relevant changes.

Memoriam

The memory space occupied for the code can be a little larger if it has several functions instead of one. But this is derisory in most cases. In PHP even more. And optimizations can make what looks intuitive show the opposite. On the other hand smaller functions can be distributed in multiple files and less code would be interpreted unnecessarily. This would generate a performance gain in the interpretation of script PHP. It is a gain that is not fully related to the size of the function. But again, the gain will probably not be relevant.

The space occupied in stack also can vary a little in some cases. Of course call separately small functions that are not being stacked in the stack, that is, when one ends (doing the pop on the stack), goes back to its caller and a new function is invoked (making a push), tends to occupy a little less space than the stack (note that the size of the stack in itself, it is usually fixed, so the consumption of the total memory is never altered in this case), but it is derisory. If you are running the risk of bursting the capacity of the stack there is something very wrong in your application and directly it is not because made a function too large or too small.

The variables allocated in stack are usually quite small. They are primitive values that fit in the processor register, including pointers to existing objects in the heap. In languages where it is possible to determine large allocation volumes in stack, the programmer needs to know what they are doing and know that they need to dislocate or terminate a scope to force the release of stack. One of the ways to close the scope is to close the function, but it doesn’t have to be so. Even these cases are rare.

The most common language is to have a Garbage Collector and the existing types in the language have semantics that determines what should be in the stack and what should be in the heap. The scope can determine whether an object in the heap should be eliminated soon or not. And we already know that the end of the function is a possibility of end of scope. So smaller functions, which contain fewer variables, in theory, can save memory. But let’s take a closer look.

• If memory management is manual we know it is a decision of the programmer when removing objects from the heap and he has freedom to release the memory when he feels like it. The size and quantity of functions do not usually influence anything.

• When using some form of automatic memory management, probably using a reference count, the end of the scope is critical to release the heap occupied from this scope (which may be the function). So it may be that having a smaller function, help reduce memory consumption. You only have the variables necessary for that part of the problem. Of course, if you somehow return a variable value of this function to the caller that passes to another function, that is, the reference count does not Zera, the object remains there. Most of the time this doesn’t matter much. Even when it matters you need to be aware of all the implications of what you’re doing. And note that in general the release is made at the end of the scope that may or may not be the end of the function.

  Splitting a function into several small ones to release faster memory may not be the solution if the memory is "bogged down". It can even create complications that hinder the solution.

  If there really is a resource that is occupying much of the heap and is not being used is probably possible to release it by assigning null for the variable. Anyway if you have variables that are no longer used in part of a function, it’s likely that it’s doing more than one thing, it’s a organizational problem.

• If you use GC tracker, which is increasingly common in most languages, memory will only be released when needed, so it has less relevance yet. Still you may need a release while you are inside a function. It falls into the same previous problem. The only solution is to force a release of the variable that references an object for GC to release the heap. You don’t have to finish the job for this. Of course in a smaller function it is more difficult to happen such a problem, but probably the problem is not the memory, it is the design.

I don’t have any data on PHP but if you have memory problems you probably have problems that depend on the size of the function. You have to understand other things that are being done wrong. PHP should not be used for problems that need special memory care to the point that determining the size of the function is critical to achieving the right result.

Remember that the design very fragmented can hinder manual or automatic tracking and end up holding data in the heap longer than necessary.

Completion

In PHP it is easy to answer that no, at least not in a relevant way. Do not choose small or large functions because of this.

In a language like C it is possible that there is some gain for one side or the other, but it is rare that the gain is relevant and necessary and only analyzing each case to determine whether the best is the function to be smaller or larger.