Open staabm opened 7 months ago
@staabm yes, the best optimization would be to remove the adapter layer from PHPStan :)
I'm OK with merging this, but it will eventually be re-factored again to an array_map()
later on anyway :|
I'm convinced method tracing is actually inflating this more than it actually is relevant.
I'd rather memoize cases
instead, in future.
lets remove the
array_map()
magic and the unnecessary closure invocation
FWIW, array_map()
is less magic than loops in general: it's just that the engine suuuuucks at handling it :-P
FWIW,
array_map()
is less magic than loops in general
I feel array_map
makes me read code backwards. I really like the simplicity of foreach
. maybe I suck in reading it as much as the engine ;-)
You need to spend a couple months writing FP (Rust, Haskell, clojure, etc.), and then C-style loops start looking like the garbled mess that they are ;-)
I'd rather memoize
cases
instead, in future.
done
please advice on how to make psalm happy or how/where to move this thing ;)
I can try helping later tonight, but currently stuck with another issue at work.
My opinion - this kind of micro optimization isn't worth it. It's only showing 8 % improvement in PHPStan because it's working with huge amounts of data. Once the root cause in PHPStan is fixed then the improvement isn't going to be 8 %, but barely measurable.
The root cause was already fixed: https://github.com/phpstan/phpstan-src/pull/2985
Most likely, but spiking memoization as a general outcome is still worth pursuing :D
I am fine with closing it
the method is showing up in profiles of https://github.com/phpstan/phpstan/issues/10772 I am aware that this PR will not fix the root cause of the perf problem, but its a low hanging fruit on my way :)
lets remove the
array_map
magic and the unnecessary closure invocation