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

Optimize a bit bfs and dfs iterators #381

Closed
wants to merge 2 commits into from

Conversation

Tortar
Copy link
Contributor

@Tortar Tortar commented Jun 3, 2024

in particular, bfs is like 40% faster

Copy link

codecov bot commented Jun 3, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.31%. Comparing base (43f9f18) to head (7e5f2a8).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #381   +/-   ##
=======================================
  Coverage   97.31%   97.31%           
=======================================
  Files         120      120           
  Lines        6954     6956    +2     
=======================================
+ Hits         6767     6769    +2     
  Misses        187      187           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment on lines -79 to -81
if state.n_visited == nv(graph)
return nothing
end
Copy link
Member

Choose a reason for hiding this comment

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

Does that have any influence on performance? Because I feel like expliectly stating that we return nothing in that case makes it easier to understand what is going on.

@simonschoelly
Copy link
Member

I see why dfs should always be faster, as there the only improvement there is using @inbound and the rest seems to be renaming. For bfs a statement like makes it 40% faster needs some explanation. At least on what kind of graphs - but better with the whole benchmark setup.

I am saying this, because we also had the case, that people just tested performance on graphs that did not really fit the problem. Therefore I think we should publish the whole methodology when testing for speedup

@Tortar
Copy link
Contributor Author

Tortar commented Jun 4, 2024

closing in favour of #382

@Tortar Tortar closed this Jun 4, 2024
@Tortar Tortar deleted the patch-3 branch June 4, 2024 15:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants