Importing/aliasing function names and performance

Toanir

Hi y'all.

I have come across a practice of aliasing core functions to improve performance and I'm quite unsure about how should I feel about that. I have been told that it saves one function-exist check with current namespace (eg. first the interpreter tries to call App\Model\in_array and if that fails, it tries just in_array) and when enforced across the project, it saves about 1 to 2 ms per request.

I'm rather bitter about this decision because it pollutes the beginning of the file. This was defended that “It doesn't matter because everyone has a smart IDE that folds these anyways.” While I partially agree about the folding, I still think that number of imports matter as it's a hint of how much concerns class in the file might bear.

Maybe I'm also baffled because in the legacy codebase we have way too much occurrences of 1+N queries and in some cases we have serious nesting issues with up to 5 levels of cycles, each introducing new query.

Anyways back to the question at hand. I wanted to ask you guys if you ever needed to concern yourselves by doing something like this:

<?php
namespace App\Model;
use function in_array;

class HealthAgency {
  public function protectsFromCovid19($protectiveMeasure) {
    return in_array($protectiveMeasaure, ['respirator-FFP3', 'face-mask']);
  }
}
?>

jiri.pudil

Hi there. Yes, it saves one additional check per every function call, so in a large-enough project, it might actually make a difference.

Another option – which does not “pollute” the file header, but “pollutes” the code instead – is to reference the functions from the global NS explicitly (i.e. with a leading backslash):

return \in_array($protectiveMeasaure, ['respirator-FFP3', 'face-mask']);

I personally use this approach, but I usually don't have any problems contributing to projects that use function imports because the IDE takes care of everything. Since both options have the same effect, I'd say it's just a matter of taste.

Marek Bartoš

This is minor optimalization with almost unnoticeable performance boost (with well-writen, opcache enabled codebase). If you can't solve it automatically with coding standard rules or IDE settings then, I would say, it's a waste of time.
opcode configuration, optimized queries and up-to-date dependencies can do way more.

Last edited by Mabar (2020-03-19 18:03)

Felix

I'd prefer some composer plugin, e.q. https://github.com/…-backslasher.

Toanir

Those are some interesting points. My opinion on this is that it feels like a question of needless micro-optimisation or rather question of dogmatic coding style decision.

I feel like I don't want to concern myself by squeezing units of microseconds and I consider not importing the global-namespace stuff more readable and more important to me.

The DG/composer-backslasher looks like a very neat package and brings up another question of what is the ratio of the executed application code to executed vendor code per request. I'm almost sure we don't really do anything about vendor and most of our dependencies do not consider this kind of optimisation. Either way thanks for linking it! :)