Measuring performance is a difficult task. All the benchmarks on this page are synthetic in the sense that they test one function repeatedly. Measurements in live systems are much harder to produce reliably. So take the following data with a grain of salt. That being said, a stated feature of the sortedcontainers Module is performance so it would be negligent not to produce this page with comparisons.
The source for all benchmarks can be found under the “tests” directory in the files prefixed “benchmark.” Measurements are made from the min, max, and average of 5 repetitions. In the graphs below, the line follows the average and at each point, the min/max displays the bounds. Note that the axes are log-log so properly reading two different lines would describe one metric as “X times” faster rather than “X seconds” faster. In all graphs, lower is better. Measurements are made by powers of ten: 10, 100, 1,000, 10,000, and 100,000.
Measurements up to 100,000,000 elements have been successfully tested but are impractical for publishing. Only a couple implementations (including sortedcontainers) are capable of handling so many elements. The major limiting factor at that size is memory. Consider the simple case of storing Python’s integers in a SortedList. Each integer object requires ~36 bytes so a hundred million elements will require about four gigabytes of memory. If the implemenation adds significant overhead then most systems will run out of memory. For all datasets which may be kept in memory, sortedcontainers is an excellent choice.
A good effort has been made to find competing implementations. Six in total were found with various list, set, and dict implementations.
Several competing implementations were omitted because they were not easily installable or failed to build.
The most similar module to sortedcontainers is skiplistcollections given that each is implemented in Python. But as is displayed below, sortedcontainers is several times faster and provides a richer API. Often the pure-Python implementation in sortedcontainers is faster even than the C-implementation counterparts. Where it lacks, performance is generally on the same magnitude.
Because sortedcontainers is implemented in pure-Python, its performance depends directly on the Python runtime. A runtime performance comparison is also included with data from popular runtimes.
SortedContainers uses a segmented-list data structure similar to a B-tree limited to two levels of nodes. As part of the implementation, a load factor is used to determine how many values should be stored in each node. This can have a significant impact on performance and a load factor performance comparison is also provided.
Though these benchmarks exercise only one API repeatedly, an effort has also been made to simulate real-world workloads. The simulated workload performance comparison contains examples with comparisons to other implementations, load factors, and runtimes.
A couple final notes about the graphs below. Missing data indicates the benchmark either took too long or failed. The set operations with tiny, small, medium, and large variations indicate the size of the container involved in the right-hand-side of the operation: tiny is exactly 10 elements; small is 10% of the size of the left-hand-side; medium is 50%; and large is 100%. The sortedcontainers module uses a different algorithm based on the size of the right-hand-side of the operation for a dramatic improvement in performance.
Graphs comparing SortedList performance.
Graphs comparing SortedDict performance.
Given a key at random, test whether the key is in the dictionary using SortedDict.__contains__.
Graphs comparing SortedSet performance.