-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Finder] added scanner adapter #8685
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
Conversation
Nice performances ! 👍 |
{ | ||
$this->excludedNames = $excludedNames; | ||
|
||
$this->minDepthRespected = 0 === $minDepth |
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 something like:
if (0 !== $minDepth) {
$this->minDepthRespected = function ($depth) use ($minDepth) { return $depth >= $minDepth; };
}
and later on:
public function isMinDepthRespected($depth)
{
if (!$this->minDepthRespected instanceof \Clousure) {
return true;
}
return call_user_func_array($this->minDepthRespected, array($depth));
}
Or something similar, IMO looks more clear =) What do you think?
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.
It's more readable yes, but it introduces a test inside isMinDepthRespected()
method which is called inside a loop and will surely impact performences. Don't you think?
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 suggest you to benchmark it. Is the overhead of the instanceof check bigger than the overhead of a function call to return true ?
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.
Do you think a function call itself has a big overhead? I'll perform benchs on this because this pattern is used almost 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 some overhead for method calls compared to doing the return directly.
And this overhead becomes much bigger when installing XDebug (which is why there is lots of benchmarks telling array_key_exists
is far slower than isset
, which is not a function call in PHP)
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.
@stloyd well, you're right, I performed following benchmark https://gist.github.com/jfsimon/33480ec6ade7820bb313 and your solution is better than mine! I update the PR.
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.
And call_user_func
is slightly fester than call_user_func_array
(~ 115 vs 125).
@stloyd @stof I updated the |
@jfsimon What's the status of this PR? I think getting a faster PHP implementation for the finder would be nice as I would really like to get rid of all those adapters. |
|
||
private static function stringToRegex($value) | ||
{ | ||
return '~(^|/)'.preg_quote($value, '#').'(/|$)~'; |
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.
The second argument to preg_quote()
should match the delimiter being used ie ~
.
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.
Good catch, thanks!
@jfsimon Any news on this one? |
@fabpot let talk about this next friday? |
@fabpot this PR is ready! Another one removing adapters will be ready in few hours. |
Can we really remove adapters ? This would be a BC break |
The registration if the adapter in the Finder (so that it is used) is missing |
@stof thanks. I know removing adapters is a huge BC break, maybe it should done for the next Symfony major version? I submit the PR anyway... |
@jfsimon it can only be done in the next major version. They could be deprecated though |
any news on this PR? the work looks great but you should look on fabbot and the failing travis @jfsimon |
Closing in favor of #15802 |
…t to skip looping over excluded directories (nicolas-grekas) This PR was submitted for the 2.8 branch but it was merged into the 2.3 branch instead (closes #15802). Discussion ---------- [Finder] Handle filtering of recursive iterators and use it to skip looping over excluded directories | Q | A | ------------- | --- | Bug fix? | yes | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #5951, #8685 | License | MIT | Doc PR | - By implementing RecursiveIterator in FilterIterator, we can make it able to skip children of excluded branches of recursive inner iterators. We use it immediately for our main target: skip over children of excluded directories in the Finder. This is a significant performance boost when iterating over big directories, thus the "bugfix" status. Commits ------- 8c691bd [Finder] Handle filtering of recursive iterators and use it to skip looping over excluded directories
This PR improves finder performance using a pure PHP adapter.
This adapter:
Benchmark:
NB: I grouped all new classes in a single
Scanner
namespace.if () { return }
vs$closure()
followLink()
support and test it