refactor: separate statistic computation

[tristan-f-r]

We also make graph statistics lazy. Laziness isn't used in summary.py, but I assume that we'll have more computationally expensive graph statistics as SPRAS develops, especially when it can take long to compute for our larger graphs.

Most importantly, this separates graph statistics into a separate function, so we can reuse the code for graph heuristic pruning.

[read-the-docs-community]

Documentation build overview

📚 spras | 🛠️ Build #30218572 | 📁 Comparing c675ece against latest (c3b02cd)

🔍 Preview build

No files changed.

[tristan-f-r]

Building on top of this PR allows me to add graph heuristics.

Most likely, every tuning PR will be at least marked with P-medium unless it's an end result.

[agitter]

Before I can review the implementation of the change, I need to better understand what problem we are tying to solve with the change. Where will laziness be needed in the future?

we can reuse the code for graph heuristic pruning

Do we envision calling graph statistic computation twice per graph? After we compute these statistics on a graph once, shouldn't that be sufficient for an entire pass of a workflow?

[tristan-f-r]

I was going to ask @ntalluri about this, since I wasn't quite sure if we will have expensive graph heuristics or not.

Do we envision calling graph statistic computation twice per graph? After we compute these statistics on a graph once, shouldn't that be sufficient for an entire pass of a workflow?

I did decouple this from analysis: summary: enabled: true, and I imagined it like this. I didn't think about that, though: would it make sense to have graph summary statistics always enabled the moment any heuristics are enabled?

[agitter]

There could be more than one way to design this sensibly. One would be that if heuristics are enabled in the config file, that automatically generates the graph summary table. The produces more output than requested, which is slightly undesirable.

Another could be to move the heuristic calculations inside each --parameters> subdirectory, which may be where you are headed. If that is written as a file for that one pathway, it could be consumed for heuristics (or used for heuristics and then written to disk). Later, if the graph summary table is requested, it would grab the precomputed statistics from those files in the subdirectories.

[tristan-f-r]

I'll mark this as a draft for now and design something in line with your second proposal.