> The relative speed (compared to the heapq code) varies under 2.3, seeming to > depend mostly on M/N. The test case is set up to find the 1000 largest of a > million random floats. In that case the sorting method takes about 3.4x > longer than the heapq approach. As N gets closer to M, the sorting method > eventually wins; when M and N are both a million, the sorting method is 10x > faster. For most N-best apps, M is much smaller than N, and the heapq code > should be quicker unless the data is already in order. FWIW, there is C implementation of heapq at: http://zhar.net/projects/python/ Raymond Hettinger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4