fix: Faster StatementIndentationFixer

[staabm]

when re-ordering the conditions we highly reduce the number of function calls happening in a regular code base.

As PHP (tested on 8.2.12) is pretty fast, the change itself does not yield much improvements regarding runtime.

As soon as php-extensions like xdebug, blackfire or other dev-tools which incur a perf penalty on function calls are in the game we see improvements though.

running php-cs-fixer on one of our closed source projects before this PR and a php.ini like

zend_extension=xdebug
xdebug.mode=debug
xdebug.start_with_request=yes

makes a big difference though (so xdebug is just loaded).

3 runs before this PR: 1m5s, 1m11s, 1m8s
3 runs after this PR: 44s, 41s, 45s

I think people having xdebug loaded while daily work while running a dev tool like php-cs-fixer is not unusal.

---

additionally by removing function calls we improve php-cs-fixer beeing profiled, because xdebug and blackfire currently are not able to yield useful results, as there are so many function calls happening, that the function call overhead by the profiler is more visible then the actual php-cs-fixer workload.

after this PR, as we have less function calls, profiles get a bit more precise. tbh we should do a few more optimizations to bring the tooling into a state where it can be helpful for us.

[staabm]

only change is re-ordering of already existing if-elseif cases so cases which are more likely to happen are checked first

[coveralls]

coverage: 96.053%. remained the same
when pulling a64ee64 on staabm:fast-indent
into 5519faf on PHP-CS-Fixer:master.

[staabm]

grml.. blackfire reported a 30% faster execution, but doing some final tests without a profiler makes me sad as the profiled improvements don't show up without a profiler.

I think the problem is that cs-fixer is doing hundreds of millions function calls. and because of this huge amount of function calls the profiler overhead is bigger and the tool cannot provide meaningful results.

[staabm]

@Wirone I wonder whether a PR which reduces function calls would be acceptable - even if it does not improve performance and create a bit of class-internal code duplication - but would lead to more meaningful blackfire profiles..?

I see a lot of unnecessary function calls (e.g. proxying calls between tiny methods in Token.php)

[staabm]

see how frequent these top-10 functions are called

at such an high rate the blackfire profiler cannot do a good job anymore.

[Wirone]

@staabm hard to tell, if it's something within a single fixer then maybe, but if it's app-wide, then it's not a question for me, as we have agreement that architectural decisions must go through @keradus 😅.

[staabm]

I would look into the Token.php class only, which seem to be a high roller as per screen above

[Wirone]

Tokens and Token are part of the public API (used by custom fixers), so changes there have to be backward compatible. You can try, but most likely it will wait for Keradus' decision 🙂.

[staabm]

just re-phrased the use-case and the PR description. I think the change itself is still valuable

[mvorisek]

I am just curious, how does Blackfire compare with xdebug? Any experience with some sampling profilers like https://github.com/nikic/sample_prof or https://github.com/reliforp/reli-prof?

[staabm]

I have no experience with other profilers then xdebug and blackfire