Message381759
Currently, all the slices are created by the interpreter with BUILD_SLICE preceded by 2/3 LOAD_CONSTS. We can move the slice creation into the compiler and deduce the cost of these 3/4 instructions into a single LOAD_CONST operation where all values in the slices are constants (like [:1], [::2], [-1]) which I assume the most common type.
There are over 93.000 constant slices in 3.200~ PyPI packages, which I'd assume is a huge amount (ofc I don't claim to know that whether these are in loops / hot functions or static globals).
Making these folding could save up to 1.32x on very common slicing behaviors (like <a list>[:1]). Here are the benchmarks (thanks to @pablogsal);
*** -s "a=list(range(200))" "a[:1]"
Mean +- std dev: [baseline] 61.8 ns +- 0.3 ns -> [optimized] 47.1 ns +- 0.2 ns: 1.31x faster (-24%)
*** -s "a=list(range(200))" "a[1:1:1], a[::1], a[1::], a[1::1], a[::-1], a[-1::], a[:], a[::]"
Mean +- std dev: [baseline] 2.38 us +- 0.02 us -> [optimized] 2.24 us +- 0.02 us: 1.06x faster (-6%)
The macro benchmarks appeared to be +1.03x increase which is assumed as noise, so this is a targeted optimization.
One problem with slices being constants is that, the code objects are hashable so does all the items in the co_consts tuple (also the internal dict that the compiler uses to store all co_const items). For allowing slices to be stored in the code objects, and not changing any behavior in a backward-incompatible way I'm proposing to make the slice objects hashable. It might not be seen as a feature, but a side-effect caused by this optimization. |
|
Date |
User |
Action |
Args |
2020-11-24 17:11:37 | BTaskaya | set | recipients:
+ BTaskaya, pablogsal |
2020-11-24 17:11:37 | BTaskaya | set | messageid: <1606237897.31.0.957567165008.issue42454@roundup.psfhosted.org> |
2020-11-24 17:11:37 | BTaskaya | link | issue42454 messages |
2020-11-24 17:11:36 | BTaskaya | create | |
|