-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
faster TypeCombinator
#747
Conversation
-> ~18% less "count()" calls in my first small tests
@@ -391,7 +391,7 @@ public static function union(Type ...$types): Type | |||
unset($tempTypes[$i]); | |||
} | |||
|
|||
if (count($tempTypes) === 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should replace count($xy) === 0
with $xy === []
all over the codebase via a cs fixing rule?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the same is true for count($xy) !== 0
and $xy !== []
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should replace
count($xy) === 0
with$xy === []
all over the codebase via a cs fixing rule?
At work I always write "count($x) === 0" because its more readable, but here the code will be called very very often and it seems to make a difference if we call it 100000x so I don't know if we should change it everywhere? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no significant performance gain between them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I also tested it and had a quick research and count()
is O(1) since the number of elements is stored in the
HashTable. So, the performance benefit in this PR was maybe from not interacting with the array at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly
please try to add a I don't have a codebase where |
Isn't there a fixer for it? 🤔 |
Yep in php-cs-fixer it is. Phpstan uses slevomat and I dont know its supported with it in the same fashion |
I think this Sniff will automatically fix it: SlevomatCodingStandard.PHP.OptimizedFunctionsWithoutUnpacking @ondrejmirtes should we use it? 🤔 |
Slevomat CS definitely has a sniff to enforce using all functions, but I don't like that codestyle and I think it has negligible impact on performance. I'd accept a change that makes the PHAR compiler do it (https://github.com/phpstan/phpstan-src/tree/master/compiler) because that's where I think it belongs, but I don't want it in phpstan-src. |
Thank you! |
@staabm @ondrejmirtes one maybe stupid question : why can't php optimize |
@voku It probably could, raise that on https://bugs.php.net/ :) |
But maybe not, you have to think of edgecases like |
Maybe it can be optimised for "normal" arrays? |
within namespaced code, php can optimize |
https://blackfire.io/profiles/compare/a42e1474-696b-4854-8eeb-0b5ea9869b77/graph ~18% less
count
calls ⇒ ~6% faster overall