Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Finder] Fix recursive filter iterator #15824

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

Merged
merged 1 commit into from
Sep 17, 2015

Conversation

nicolas-grekas
Copy link
Member

Q A
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #15802
License MIT
Doc PR -
#15802 was broken because the filters where not propagated to children iterators. This fixes the issue and adds a test case for this situation. The RecursiveIterator implementation is moved from FilterIterator to ExcludeDirectoryFilterIterator. Doing so on other filters is possible but would be a new feature that is not required for fixing the performance issue we had previously.

@@ -22,12 +22,12 @@
{
public function hasChildren()
{
return $this->getInnerIterator() instanceof \RecursiveIterator && $this->getInnerIterator()->hasChildren();
return $this instanceof RecursiveAwareIterator && $this->getInnerIterator() instanceof \RecursiveIterator && $this->getInnerIterator()->hasChildren();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a good reason to avoid implementing RecursiveIterator in our FilterIterator class and putting the implementation of this interface in each filter instead (i.e. only ExcludeDirectoryFilterIterator for now)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, fixed!

@stof
Copy link
Member

stof commented Sep 17, 2015

👍

@nicolas-grekas nicolas-grekas merged commit cf3019b into symfony:2.3 Sep 17, 2015
nicolas-grekas added a commit that referenced this pull request Sep 17, 2015
This PR was merged into the 2.3 branch.

Discussion
----------

[Finder] Fix recursive filter iterator

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #15802
| License       | MIT
| Doc PR        | -

#15802 was broken because the filters where not propagated to children iterators. This fixes the issue and adds a test case for this situation. The RecursiveIterator implementation is moved from FilterIterator to ExcludeDirectoryFilterIterator. Doing so on other filters is possible but would be a new feature that is not required for fixing the performance issue we had previously.

Commits
-------

cf3019b [Finder] Fix recursive filter iterator
@nicolas-grekas nicolas-grekas deleted the fix-finder branch September 17, 2015 12:15
fabpot added a commit that referenced this pull request Sep 18, 2015
This PR was merged into the 2.3 branch.

Discussion
----------

[Finder] Optimize the hot-path

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #15824
| License       | MIT
| Doc PR        | -

A significant part of the perf gain in #15802 was related to filters not being applied recursively...
#15824 fixing this, performance dropped again.

This PR optimizes the hot path by replacing a regexp test by a simple `isset` when possible.
Blackfire diff after #15824 is the following:
https://blackfire.io/profiles/compare/9e489018-998d-4acb-92a0-46011828e83b/graph

`preg_match` is not called anymore, and  `Symfony\Component\Finder\Iterator\RecursiveDirectoryIterator::current()` is also cut by two.

When this `isset` optimization is disabled and replaced by a concatenation of all the regexps patterns in a single bigger one, the gain is still significant but lower:
https://blackfire.io/profiles/compare/db86b80e-b63e-4fc9-9ff3-9ed32baeb948/graph

This makes me think that an other and last round of optimization is possible by merging all regexps in one in MultiplePcreFilterIterator filters. If someone wants to work on this, please do it :)

Commits
-------

f156de6 [Finder] Optimize the hot-path
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants