Would the byte code compiler optimize this or should I?

[DavesCodeMusings]

The example shown in one_liner() below calls the .encode() method twice. One might assume this runs the same thing two times and would be better written as shown in two_liner(). But, I've always heard: "The compiler optimizes better than you do."

So my question is, would the MicroPython bytecode compiler look at one_liner(), recognize that it's using the same thing twice on one line, and therefore calculate it only once and substitute that result in both places?

def one_liner(value):
  return bytes([len(value.encode())]) + value.encode()

def two_liner(value):
  encoded_value = value.encode()
  return bytes([len(encoded_value)]) + encoded_value

[peterhinch]

You can test this yourself if you compile the Unix build - this produces a file ports/unix/build-standard/micropython. Put your Python code in a file and run

$ micropython -v -v my_module.py

It will print the emitted bytecode.

Bear in mind that the MP compiler has to run on extremely resource-constrained hardware so may not be as heavily optimised as, say, gcc. I always cache results as in your second example.

[Josverl]

Another option is to use mpy-cross -O2 small.py in combination with python tools/mpy-tool.py small.mpy -d > xxxliner.dmp
Then you can see that the bytecode is different,
I personally can't tell which version is better though ....

You can then experiment with different compiler options and compare the output in your diff viewer of choice.

Details

or

diff --git "a/.\\oneliner.dmp" "b/.\\twoliner.dmp"
index 92117f4..0a67726 100644
--- "a/.\\oneliner.dmp"
+++ "b/.\\twoliner.dmp"
@@ -1,11 +1,11 @@
-mpy_source_file: small.mpy
-source_file: small.py
+mpy_source_file: small2.mpy
+source_file: small2.py
 header: 4d:06:00:1f
 arch: NONE
 qstr_table[7]:
-    small.py
+    small2.py
     <module>
-    one_liner
+    two_liner
     encode
     value
     bytes
@@ -17,26 +17,26 @@ simple_name: <module>
   args: []
   line info: 
   32:00       MAKE_FUNCTION 0
-  16:02       STORE_NAME one_liner
+  16:02       STORE_NAME two_liner
   51          LOAD_CONST_NONE 
   63          RETURN_VALUE 
-  children: ['one_liner']
-simple_name: one_liner
-  raw bytecode: 27 21:06:02:04:20:12:05:12:06:b0:14:03:36:00:34:01:2b:01:34:01:b0:14:03:36:00:f2:63
+  children: ['two_liner']
+simple_name: two_liner
+  raw bytecode: 26 21:08:02:04:20:26:b0:14:03:36:00:c1:12:05:12:06:b1:34:01:2b:01:34:01:b1:f2:63
   prelude: (5, 0, 0, 1, 0, 0)
   args: ['value']
-  line info: 20
-  12:05       LOAD_GLOBAL bytes
-  12:06       LOAD_GLOBAL len
+  line info: 20:26
   b0          LOAD_FAST 0 
   14:03       LOAD_METHOD encode
   36:00       CALL_METHOD 0
+  c1          STORE_FAST 1 
+  12:05       LOAD_GLOBAL bytes
+  12:06       LOAD_GLOBAL len
+  b1          LOAD_FAST 1 
   34:01       CALL_FUNCTION 1
   2b:01       BUILD_LIST 1
   34:01       CALL_FUNCTION 1
-  b0          LOAD_FAST 0 
-  14:03       LOAD_METHOD encode
-  36:00       CALL_METHOD 0
+  b1          LOAD_FAST 1 
   f2          BINARY_OP 27 __add__ 
   63          RETURN_VALUE 
   children: []

[peterhinch]

I personally can't tell which version is better though ....

Well, if encode() takes ten seconds I think we can guess which will be faster...

[cwalther]

Even if the compiler were super-smart at optimizing, it could not optimize your one_liner into the two_liner, because it cannot assume that value.encode() returns the same thing every time it is called and has no side effects that you want twice. Whether it does is entirely dependent on what kind of object value is, and that is not known at the time the function is compiled.

[Josverl]

unless the compiler can determine it is "pure function", at least that is what CPython's JIT compiler does IIUC

[cwalther]

It cannot determine that in this case, that’s my point. The one_liner as written here needs to work both with encode methods that are pure and ones that are not. Best thing the compiler could do is compile two versions of it and dispatch between them depending on what value is.