Addressing Slower Parallel Implementations in nx-parallel Compared to NetworkX

[Schefflera-Arboricola]

Description:

Need to address the performance of certain algorithms in the nx-parallel whose parallel implementations are currently slower than their corresponding implementations in NetworkX. Some of these algorithms include:

• v_structures in ENH: added colliders and v_structures #74
• colliders in ENH: added colliders and v_structures #74
• global_reaching_centrality in ENH : Added algos in centrality/reaching.py #44
• local_reaching_centrality in ENH : Added algos in centrality/reaching.py #44
• average_clustering
• approximate_average_clustering
• number_of_isolates

Issues to Discuss:

1. Performance Comparison: What should we do with these functions that show slower performance in their parallel implementations? Should we consider reverting to or recommending the use of NetworkX's implementation in these cases?

2. Optimization: Is there a more optimized way that would improve the performance of these parallel implementations? And will that be way better the performance for all the algorithms? And how can we give the control of changing these "ways" to the end user?

3. Functionality: There are also some graph algorithms that cannot be parallelized due to their fundamentally non-parallelizable nature. How should we handle such algorithms in nx-parallel? Should we provide a clear indication in the documentation or in the code itself? Or not add them to nx-parallel at all?

Next Steps:

• Gather insights and suggestions from the community.
• Determine whether to optimize, remove, or replace the slower parallel implementations.
• Identify any non-parallelizable functions and decide on how to best handle them.

Thank you :)