Note performance trade-offs of various design strategies.
This commit is contained in:
parent
faf8e74815
commit
cdabe86aab
18
pep-0372.txt
18
pep-0372.txt
|
@ -224,6 +224,24 @@ How does odict handle equality testing?
|
|||
explicitly craft an order based comparison:
|
||||
``list(od1.items())==list(od2.items())``.
|
||||
|
||||
What are the trade-offs of the possible underlying data structures?
|
||||
|
||||
* Keeping a sorted list of keys is very fast for all operations except
|
||||
__delitem__() which becomes an O(n) exercise. This structure leads to
|
||||
very simple code and little wasted space.
|
||||
|
||||
* Keeping a separate dictionary to record insertion sequence numbers makes
|
||||
the code a little bit more complex. All of the basic operations are O(1)
|
||||
but the constant factor is increased for __setitem__() and __delitem__()
|
||||
meaning that every use case will have to pay for this speedup (since all
|
||||
buildup go through __setitem__). Also, the first traveral incurs a
|
||||
one-time ``O(n log n)`` sorting cost. The storage costs are double that
|
||||
for the sorted-list-of-keys approach.
|
||||
|
||||
* A version written in C could use a linked list. The code would be more
|
||||
complex than the other two approaches but it would conserve space and
|
||||
would keep the same big-oh performance as regular dictionaries. It is
|
||||
the fastest and most space efficient.
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
|
Loading…
Reference in New Issue