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.