So here is my timings:
>>> import timeit
>>> timeit.timeit(lambda: set(l))
0.7210583936611334
>>> timeit.timeit(lambda: {*l})
0.5386332845236943
Why is that, my opinion would be equal but it's not.
So unpacking is fast from this example, right?
For the same reason []
is faster than list()
; the interpreter includes dedicated support for syntax based operations that uses specialized code paths, while constructor calls involve:
- Loading the constructor from built-in scope (requires a pair of
dict
lookups, one in global scope, then another in built-in scope when it fails) - Requires dispatch through generic callable dispatch mechanisms, and generic argument parsing code, all of which is far more expensive than a single byte code that reads all of its arguments off the stack as a C array
All of these advantages relate to fixed overhead; the big-O of both approaches are the same, so {*range(10000)}
won't be noticeably/reliably faster than set(range(10000))
, because the actual construction work vastly outweighs the overhead of loading and calling the constructor via generic dispatch.
来源:https://stackoverflow.com/questions/53219640/why-is-l-faster-than-setl-python-sets-not-really-only-for-sets-for