Author inada.naoki
Recipients inada.naoki, rhettinger, serhiy.storchaka
Date 2017-08-23.15:11:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1503501114.99.0.170229113489.issue31265@psf.upfronthosting.co.za>
In-reply-to
Content
I think typical usage is: get, set (incl, creating), and iterate.

* get: there is no difference
* set: inserting new key is little faster since no updating linked list
* iterate: in typical case, new odict is faster because current odict iterator do lookup for each key.

$ ./py-patched -m perf timeit --compare-to `pwd`/py-default \
  -s 'from collections import OrderedDict as odict; od = odict.fromkeys(range(10000))' -- 'list(od)'

py-default: ..................... 223 us +- 10 us
py-patched: ..................... 93.7 us +- 3.3 us
Mean +- std dev: [py-default] 223 us +- 10 us -> [py-patched] 93.7 us +- 3.3 us: 2.38x faster (-58%)


On the other hand, there are some cases new odict is slower:

* iterating sparse dict. (but same speed as normal dict)
* comparing two odict, because new odict do `list(od1) == list(od2)` to compare keys.

For now, new odict uses dict's iterator (with adding `reversed` order support) and it's weak
against modify while iterating.  That's why I used temporal list while comparing.
And there is one failing test for modify-while-iterate case.

So I'm thinking about implementing robust odict iterator which detect modify for now.
History
Date User Action Args
2017-08-23 15:11:55inada.naokisetrecipients: + inada.naoki, rhettinger, serhiy.storchaka
2017-08-23 15:11:54inada.naokisetmessageid: <1503501114.99.0.170229113489.issue31265@psf.upfronthosting.co.za>
2017-08-23 15:11:54inada.naokilinkissue31265 messages
2017-08-23 15:11:54inada.naokicreate