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

Skip to content

Conversation

GroteGnoom
Copy link
Member

part of #2300

|> Benchmark file: /home/daniel/Documents/igraph/tests/benchmarks/error_checking.c
| singleton graph                                                                      0s      0s      0s
| graph with 50000000 nodes, no edges                                              0.061s   0.01s  0.052s
| vector init of 50000000                                                              0s      0s      0s
| vector fill of 50000000 INFINITY                                                 0.049s  0.006s  0.043s
| vector destroy                                                                   0.001s      0s      0s
| vector fill of 50000000 1s                                                       0.048s  0.006s  0.042s
| 50000000 vertices ring graph astar from 0 to 0, 1x                               0.092s  0.051s  0.041s
| 50000000 vertices ring graph astar from 0 to 50000000 -1, 1x                      4.01s   3.14s  0.865s
| 10000 vertices full graph astar from 0 to 0, 1x                                  0.031s  0.031s      0s
| vector_min on 50000000 numbers 1x                                                0.031s  0.031s      0s
| 2wheap init of 50000000, 1x                                                          0s      0s      0s
| IGRAPH_CALLOC of 50000000 igraph_integer_t, 1x                                       0s      0s      0s
| 2wheap destroy                                                                       0s      0s      0s

Added some benchmarks for things that almost take no time, because they did take a significant amount of time with a debug build with sanitizers on.
So for the case where you path length is negligible:
just checking weights (vector_min) takes up almost all the time for the full graph.
error checking + filling the dists vector (which scales with no_of_nodes) takes about 8/9 of the time for the ring graph. I find it difficult to find where the rest of the time goes.
I've also put in the longest path scenario, then the overhead is less than 1/40.

@GroteGnoom GroteGnoom marked this pull request as draft April 30, 2023 10:02
@codecov
Copy link

codecov bot commented Apr 30, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.50%. Comparing base (d789a7e) to head (2aeab22).
Report is 1291 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #2342   +/-   ##
=======================================
  Coverage   83.50%   83.50%           
=======================================
  Files         376      376           
  Lines       61549    61549           
=======================================
  Hits        51399    51399           
  Misses      10150    10150           

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d789a7e...2aeab22. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@szhorvat
Copy link
Member

szhorvat commented May 5, 2023

Even though this would be difficult for us to implement (without moving to C++), I wanted to mention that some systems store metadata for vectors that indicate the vector contents. For example, I think recent R versions keep track of whether a vector contains NA / NaN. Mathematica appears to do something similar (although strictly speaking it doesn't allow NaNs in vectors). This is much like the cache we use in igraph_t.

If we did have this feature, it could speed up check. We could even set this cache when transferring vectors from R or Mathematica.

But in plain C, there is no good way that I can think of to catch vector modification operations and clear this cache. So I don't think we can do it now. C++ would be different ...

@szhorvat
Copy link
Member

szhorvat commented May 5, 2023

In some cases, the input checks can be moved into the core algorithm. This may be an advantage (when the algorithm accesses only a small fraction of edges and their weights) or a disadvantage (which the algorithm accesses the same edge / weight many times).

Copy link

stale bot commented Apr 26, 2025

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Issues that have been inactive for a long time; will be closed in the absence of further activity label Apr 26, 2025
@szhorvat szhorvat added todo Triaged for implementation in some unspecified future version and removed stale Issues that have been inactive for a long time; will be closed in the absence of further activity labels Apr 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

todo Triaged for implementation in some unspecified future version

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants