Skip to content
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

Fix performance regression of some find() methods #25489

Closed
nalimilan opened this issue Jan 10, 2018 · 0 comments · Fixed by #25879
Closed

Fix performance regression of some find() methods #25489

nalimilan opened this issue Jan 10, 2018 · 0 comments · Fixed by #25879
Labels
performance Must go faster regression Regression in behavior compared to a previous version search & find The find* family of functions

Comments

@nalimilan
Copy link
Member

Changes to find made by #24774 introduced some performance regressions (see #24774 (comment)). Unless push! can be made efficient enough (#24909), we should probably introduce a specialized method for AbstractArray{Bool} which would compute the number of true entries, allocate a vector of the required size and fill it, as was done before. This is not possible for general iterables since it is not guaranteed that they can be accessed several times, but it should be possible to also apply this strategy to generators, when the backing iterator is an array.

find also appears to have slightly regressed on generators, but it's not clear whether this regression is real nor why it happens. If new Nanosoldier runs confirm it, it should be investigated.

@nalimilan nalimilan added performance Must go faster regression Regression in behavior compared to a previous version search & find The find* family of functions labels Jan 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Must go faster regression Regression in behavior compared to a previous version search & find The find* family of functions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant