avoid allocations by avoiding **kwargs

[dhalbert]

• Avoid using *args and **kwargs, which allocate storage.
• Do hasattr() once and remember its value.

There is a remarkable timing peculiarity when doing this right now, using this test program, running on a CPB:

import time
import adafruit_lis3dh
from adafruit_circuitplayground import cp

def time_it(f, n):
    heap_before = gc.mem_free()
    s = time.monotonic()
    for _ in range(n):
        f()
    heap_after = gc.mem_free()
    return "secs: {}, heap: {}".format(time.monotonic() - s, heap_before - heap_after)

def read_reg():
    cp._lis3dh._read_register(0x28 | 0x80, 6)

def read_reg_then_unpack():
    struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6))

for n in (1,40,50,400,1000):
    gc.collect()
    print(n, "cp._lis3dh._read_register:",
          time_it(read_reg, n))
    gc.collect()
    print(n, "struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)):",
          time_it(read_reg_then_unpack, n))
    print()

Test program output _ before_ applying this PR is below. @tannewt Notice the bizarre result for the 400 and 1000 cases above, where simply reading the register is slower than reading the register and then unpacking the result. This may be ameliorated by your proposed heap allocation improvements.

1 cp._lis3dh._read_register: secs: 0.00976563, heap: 96
1 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 0.00976563, heap: 128

40 cp._lis3dh._read_register: secs: 0.0664063, heap: 3840
40 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 0.0644531, heap: 5120

50 cp._lis3dh._read_register: secs: 0.0800781, heap: 4800
50 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 0.0820313, heap: 6400

400 cp._lis3dh._read_register: secs: 0.763672, heap: 38400
400 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 0.587891, heap: 51200

1000 cp._lis3dh._read_register: secs: 2.54102, heap: 96000
1000 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 1.45508, heap: 128000

Test program output with this PR:

1 cp._lis3dh._read_register: secs: 0.0117188, heap: 0
1 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 0.0078125, heap: 32

40 cp._lis3dh._read_register: secs: 0.078125, heap: 0
40 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 0.0898438, heap: 1280

50 cp._lis3dh._read_register: secs: 0.0820313, heap: 0
50 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 0.109375, heap: 1600

400 cp._lis3dh._read_register: secs: 0.621094, heap: 0
400 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 1.04688, heap: 12800

1000 cp._lis3dh._read_register: secs: 1.53516, heap: 0
1000 struct.unpack('<hhh', cp._lis3dh._read_register(0x28 | 0x80, 6)): secs: 3.47656, heap: 32000

[tannewt]

Why is the struct version slower with this change?

[dhalbert]

Why is the struct version slower with this change?

That is the question!

[tannewt]

Looks great! Definitely reduces the number of allocations in the test.

[tannewt]

For those only following this conversation. The struct version is slower because there no longer single block allocations between tuple allocations, which are 2+ blocks. 2+ block allocations can get very expensive when no single block allocations occur because only single block allocations advance the start location of the allocation scan.