|
| 1 | +bind.py [](https://unlicense.org/) |
| 2 | +======= |
| 3 | +~~[wheel (GHA via `nightly.link`)](https://nightly.link/KOLANICH-libs/bind.py/workflows/CI/master/bind-0.CI-py3-none-any.whl)~~ |
| 4 | +~~[](https://github.com/KOLANICH-libs/bind.py/actions/)~~ |
| 5 | + |
| 6 | +[](https://libraries.io/github/KOLANICH-libs/bind.py) |
| 7 | +[](https://codeberg.org/KOLANICH-tools/antiflash.py) |
| 8 | + |
| 9 | +This is a tool to allow you to inline constants into functions for fun and profit. In some cases using this tool can give 30% gain of speed. In some, but not in the all ones - [in some cases it actually causes slowdown](https://codeberg.org/KOLANICH-libs/bind.py/issues/4). |
| 10 | + |
| 11 | + |
| 12 | +How does it work? |
| 13 | +----------------- |
| 14 | +It just |
| 15 | +* moves some closured and global variables into constants, taking attention to arguments |
| 16 | +* replaces "LOAD_DEREF" and "LOAD_GLOBAL" opcodes with "LOAD_CONST" |
| 17 | +* removes moved variables from function `__closure__` property |
| 18 | + |
| 19 | +Limitations |
| 20 | +----------- |
| 21 | +* When you define a function, sometimes it uses `LOAD_FAST` opcode to load. For now this case is not taken in account. |
| 22 | +* Inlined variables shouldn't be modified because they are marked as constants. Doing this can cause undefined behavior including crashes of interpreter and SIGSEGVs. Adding support for these will require some analysis of control and data flow to check if a variable is modified, spawning a local variable and loading const there. For now the function doesn't check any of such kind of usage, it's your responsibility as a programmer to guarantee this. |
| 23 | +* You should inspect bytecode (for example using `dis`) of the func you want to optimize to understand if `inline` could help. If there is no `LOAD_DEREF` and `LOAD_GLOBAL` opcodes in a function it won't help in the current state. |
| 24 | +* It doesn't modify functions' text, only bytecode. So source-code showing tools like `??` of IPython won't give accurate information. |
| 25 | +* Python can optimize some inlined functions better than this tool, for example |
| 26 | +```python |
| 27 | +def a(): |
| 28 | + return 2+3 |
| 29 | +``` |
| 30 | +in fact loads not `2` and `3` but a precomputed `5`, it will have `2` instructions smaller byte-code than |
| 31 | +```python |
| 32 | +@bind(x=2, y=3) |
| 33 | +def a(): |
| 34 | + return x+y |
| 35 | +``` |
| 36 | +* Inlining limits hackability. When a variable is inlined it cannot be monkey-patched easily by third-party code. |
| 37 | +* This is very beta for now. For now it even breaks itself when inlined. Use it on small functions where there is nothing to break. |
| 38 | +* Bytecode is implementation detail of cpython. It can and will change unexpectidly. This will make this to break. It also can be different between implementations. |
| 39 | + |
| 40 | +How to use |
| 41 | +---------- |
| 42 | +* Import the `bind` function |
| 43 | +```python |
| 44 | +from bind import bind |
| 45 | +``` |
| 46 | + |
| 47 | +* You can explicitly call the function, providing it the function to optimize and the dict of variables to bind. |
| 48 | +```python |
| 49 | +c=1 |
| 50 | +def a(a, b): |
| 51 | + print(a+c, b+d) |
| 52 | +a=bind(a, {"c":c, "d":1}) |
| 53 | +a(1, 2) # 2 3 |
| 54 | +``` |
| 55 | +* You can use it as a decorator |
| 56 | +```python |
| 57 | +c=1 |
| 58 | +@bind({"c":c, "d":1}) |
| 59 | +@bind(c=c, d=1) #kwargs-syntax also works |
| 60 | +def a(a, b): |
| 61 | + print(a+c, b+d) |
| 62 | +a(1, 2) # 2 3 |
| 63 | +``` |
| 64 | +* When used as decorator, you can also use kwargs-syntax |
| 65 | +```python |
| 66 | +@bind(c=1, d=1) |
| 67 | +def a(a, b): |
| 68 | + print(a+c, b+d) |
| 69 | +a(1, 2) # 2 3 |
| 70 | +``` |
| 71 | +* You can specify variables separately |
| 72 | +```python |
| 73 | +c=1 |
| 74 | +@bind(c=c) |
| 75 | +@bind(d=1) |
| 76 | +def a(a, b): |
| 77 | + print(a+c, b+d) |
| 78 | +a(1, 2) # 2 3 |
| 79 | +``` |
| 80 | +* Inlined variable doesn't depend on closure |
| 81 | +```python |
| 82 | +c=1 |
| 83 | +d=1 |
| 84 | +def a(a, b): |
| 85 | + print(a+c, b+d) |
| 86 | +a(1, 2) # 2 3 |
| 87 | +b=bind(a, {"c":c, "d":1}) |
| 88 | +d=4 |
| 89 | +c=4 |
| 90 | +a(1, 2) # 5 6 |
| 91 | +b(1, 2) # still 2 3 because c is inlined |
| 92 | +``` |
| 93 | +* Independence on following inlines |
| 94 | +```python |
| 95 | +b=bind(b, {"c":3, "d":4}) |
| 96 | +b(1, 2) # still 2 3 because there is no c and d anymore in that func |
| 97 | +``` |
| 98 | +* You can inline all the variables visible from the current scope. |
| 99 | +```python |
| 100 | +c=1 |
| 101 | +def a1(): |
| 102 | + c=2 |
| 103 | + def a(): |
| 104 | + print(c) |
| 105 | + c=3 |
| 106 | + return a |
| 107 | +def a2(): |
| 108 | + c=2 |
| 109 | + @bind |
| 110 | + def a(): |
| 111 | + print(c) |
| 112 | + c=3 |
| 113 | + return a |
| 114 | +b=a1() |
| 115 | +c=a2() |
| 116 | +b() # 3 |
| 117 | +c() # 2 |
| 118 | +``` |
| 119 | + |
| 120 | + |
| 121 | +Benchmark results |
| 122 | +----------------- |
| 123 | +To run the benchmark run |
| 124 | +```bash |
| 125 | +python3 benchmarkGen.py | python3 |
| 126 | +``` |
| 127 | +this wil give you the results: |
| 128 | +```javascript |
| 129 | +{ |
| 130 | + "load_global": { |
| 131 | + "orig": 45.899, |
| 132 | + "inlined": 32.968, |
| 133 | + "% faster": 30.347 |
| 134 | + }, |
| 135 | + "load_deref": { |
| 136 | + "orig": 37.911, |
| 137 | + "inlined": 32.022, |
| 138 | + "% faster": 15.532 |
| 139 | + } |
| 140 | +} |
| 141 | +``` |
| 142 | +As we see, inlined synthetic functions are really 15-30% faster! |
| 143 | + |
| 144 | + |
| 145 | +Use case |
| 146 | +-------- |
| 147 | +Situation: you have met some library. You looked into it and saw shitcode. |
| 148 | +```python |
| 149 | +class B: |
| 150 | + def b1(a): |
| 151 | + print(1+a) |
| 152 | + def b2(a): |
| 153 | + print(2+a) |
| 154 | + ... |
| 155 | + def b100500(a): |
| 156 | + print(100500+a) |
| 157 | +```. |
| 158 | +
|
| 159 | +You have have refactored this shit using |
| 160 | +```python |
| 161 | +def genBFuncs(lol="lol"): |
| 162 | + for i in range(100500): |
| 163 | + def b(a): |
| 164 | + print(i+a) |
| 165 | + b.__name__="b"+str(i) |
| 166 | + yield b |
| 167 | +``` |
| 168 | + |
| 169 | +Some folks will say |
| 170 | +> It will slow down our lib! |
| 171 | +
|
| 172 | +As we know from the benchmark, they are right. |
| 173 | + |
| 174 | +Here is the response: |
| 175 | +```python |
| 176 | +# you have a function "a" making a functions "b" for some library |
| 177 | +def genBFuncs(lol="lol"): |
| 178 | + for i in range(100500): |
| 179 | + @bind(i=i) |
| 180 | + def b(a): |
| 181 | + print(i+a) |
| 182 | + b.__name__="b"+str(i) |
| 183 | + yield b |
| 184 | +``` |
| 185 | + |
| 186 | +This will rewrite functions bytecode so it will be nearly identical to the original versions. |
0 commit comments