Fix kahns algo sparse vertex performance

[Kanika0306]

Describe your change:

• Fixes the O(N) queue operation caused by list.pop(0) by using collections.deque and queue.popleft(), ensuring constant-time dequeue operations and preserving the expected O(V + E) time complexity of Kahn's topological sort algorithm.

• Fixes an IndexError for sparse/non-contiguous integer vertex IDs by changing indegree from a list to a dictionary keyed by the graph vertices.

• Adds doctests covering topological sorting with sparse/non-contiguous integer vertex IDs.

• Adds doctests covering cycle detection with non-contiguous vertex IDs.

• Add an algorithm?

• Fix a bug or typo in an existing algorithm?

• Add or change doctests?

• Documentation change?

Checklist:

• I have read https://github.com/TheAlgorithms/Python/blob/master/CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
• If this pull request resolves one or more open issues then the description above includes the issue number(s) with a closing keyword: "Fixes #<ISSUE_NUMBER>".

Fixes #15071

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Kanika0306]

@cclauss kindly review

[Kanika0306]

@cclauss kindly review

[Kanika0306]

@mindaugl
could you kindly review this pr
Thankyou

[cclauss]

Please add a benchmark that proves that the proposed modification could save significant runtime.

[Kanika0306]

Please add a benchmark that proves that the proposed modification could save significant runtime.

Sure I will do that

[cclauss]

What are the benchmark results on your machine?

[Kanika0306]

What are the benchmark results on your machine?

Here are the benchmark results on my machine comparing the pre-optimization implementation (list.pop(0)) against the current implementation (deque.popleft()) for topological_sort() on a 30,000-vertex DAG across 5 runs:

Benchmark results for topological_sort with 30000 vertices over 5 runs:

Pre-optimization (list.pop(0)): 0.29597 seconds
Current (deque.popleft): 0.04935 seconds

Speedup ratio: 6.00x faster

The benchmark directly measures topological_sort() on the exact same graph input and programmatically asserts that both implementations return valid, complete topological sorts.

[cclauss]

@priya-sundaram-dev, please review.

[priya-sundaram-dev]

Thanks for the work here, and for caring about the pop(0) → deque.popleft() win.

I checked out refs/pull/15072/head and ran it: doctests pass (8/8), and benchmark() reports ~6.2x on my machine (list.pop(0) 0.343s vs deque.popleft 0.055s over 5 runs on 30k zero-indegree vertices), so the numbers hold up.

One thing worth flagging before this lands, though: the actual optimization (dict.fromkeys indegree + deque.popleft) is already on master. Diffing this branch against master, the only thing 15072 still adds is:

• _topological_sort_list_queue() — a ~30-line copy of the pre-optimization code, kept solely as a benchmark baseline, and
• benchmark() + a benchmark() call under __main__.

My concern is that this permanently keeps a deliberately-slower duplicate implementation in a learning-resource file. Anyone reading kahns_algorithm_topo.py now sees two topological sorts and has to figure out that one exists only to be beaten in a microbenchmark. TA/Python files are meant to be read as clean references, and the speedup is already captured by the merged change.

Suggestion: drop _topological_sort_list_queue and benchmark() from the committed file. If you'd like the benchmark preserved, it reads better as a note in the PR description (the 6.2x number you measured) than as code that ships. That leaves master with the fast version and no dead baseline.

Happy to re-review quickly whichever direction the maintainers prefer — this is a scope call, not a correctness problem.

[Kanika0306]

Thanks for the work here, and for caring about the pop(0) → deque.popleft() win.

I checked out refs/pull/15072/head and ran it: doctests pass (8/8), and benchmark() reports ~6.2x on my machine (list.pop(0) 0.343s vs deque.popleft 0.055s over 5 runs on 30k zero-indegree vertices), so the numbers hold up.

One thing worth flagging before this lands, though: the actual optimization (dict.fromkeys indegree + deque.popleft) is already on master. Diffing this branch against master, the only thing 15072 still adds is:

• _topological_sort_list_queue() — a ~30-line copy of the pre-optimization code, kept solely as a benchmark baseline, and
• benchmark() + a benchmark() call under __main__.

My concern is that this permanently keeps a deliberately-slower duplicate implementation in a learning-resource file. Anyone reading kahns_algorithm_topo.py now sees two topological sorts and has to figure out that one exists only to be beaten in a microbenchmark. TA/Python files are meant to be read as clean references, and the speedup is already captured by the merged change.

Suggestion: drop _topological_sort_list_queue and benchmark() from the committed file. If you'd like the benchmark preserved, it reads better as a note in the PR description (the 6.2x number you measured) than as code that ships. That leaves master with the fast version and no dead baseline.

Happy to re-review quickly whichever direction the maintainers prefer — this is a scope call, not a correctness problem.

Sure I will do that
Thanks for the review

[priya-sundaram-dev]

Thanks for the quick turnaround, @Kanika0306 — the shipped file is now clean and focused.

Re-reviewed refs/pull/15072/head:

• The dead list.pop(0) baseline and the microbenchmark are gone, so the module stays lean — the 6.2x number lives in the PR description where it belongs. 👍
• The real substance holds up nicely: switching indegree from a positional [0]*len(graph) list to dict.fromkeys(graph, 0) is a genuine correctness fix, not just perf — the old code silently broke on non-contiguous / sparse vertex IDs. Verified: topological_sort({10:[20], 20:[]}) → [10, 20], {10:[20], 20:[10]} → None (cycle), {0:[1,2],1:[3],2:[3],3:[]} → [0,1,2,3].
• deque.popleft() removes the O(n) shift on the BFS frontier.
• Doctests: 8/8 pass, including the new sparse_graph / sparse_cycle guards.

LGTM. 🚀

[cclauss]

Nice teamwork! given enough eyeballs, all bugs are shallow