On Thu, Jul 9, 2020 at 12:45 PM Christopher Barker email@example.com wrote:
On Wed, Jul 8, 2020 at 7:13 PM Inada Naoki firstname.lastname@example.org wrote:
I think this comparison is unfair.
well, benchmarks always lie ....
d.items() vs list(d.items())
Should be compared with `next(iter(d.items())`
why? the entire point of this idea is to have indexing syntax -- we can already use the iteration protocol top do this. Not that it's a bad idea to time that too, but since under the hood it's doing the same or less work, I'm not sure what the point is.
Because this code solves "take the first item in the dict".
If you need to benchmark index access, you should compare your dict.items() and list index. You shouldn't create list from d.items8) every loop.
d.keys()[-1] vs list(d.keys())[-1]
Should be compared with `next(reversed(d.keys()))`, or `next(reversed(d))`.
Same point - the idea is to have indexing syntax. Though yes, it would be good to see how it compares. But I know predicting performance is usually wrong, but this is going to require a full traversal of the underlying keys in either case.
Same here. And note that dict and dict views now supports reversed().
random.choice(d.items()) vs random.choice(list(d.items()))
Should be compared with `random.choice(items_list)` with `items_list = list(d.items())` setup too.
I don't follow this one -- could you explain? what is items_list ?
I explained `item_list = list(d.items())`. Do it in setup (e.g. before loop.) ("setup" is term used by timeit module.)
But what this didn't check is how bad the performance could be for what I expect would be a bad performance case -- indexing teh keys repeatedly:
for i in lots_of_indexes: a_dict.keys[i]
keys_list = list(a_dict.keys) for it in lots_of_indexes: keys_list[i]
You should do this.
I suspect it wouldn't take all that many indexes for making a list a better option.
If you need to index access many times, creating list is the recommended way. You shouldn't ignore it. That's why I said it's an unfair comparison. You should compare "current recommended way" vs "propsed way".
But again, we are badk to use cases. As Stephen pointed out no one has produced an actualy production code use case.