I had planned to make a series of tests to show how memory allocation speed changes as the amount of available memory goes down, with the idea that it could be useful information for others wanting to plan manual garbage collection cycles to speed up their own code. As I was about to start, the uPy developers started to attack the problem of gc performance directly. I am quite happy to say that this work rendered my little project moot. The improvements to the garbage collector will provide a tremendous performance boost for any code dominated by object allocation. It is also important to note that memory allocation no longer slows down as the pool of free blocks is exhausted. I wanted to make a note of that in this thread so my earlier results wouldn't give too pessimistic a view of micropython's performance.
For part of the developer discussion on the topic, see
https://github.com/micropython/micropython/issues/836
Note that the fragmentation issue discussed in #836 also seems to have been resolved.
For reference, I repeated my previous tests on a pyboard using firmware images downloaded from micropython.org:
pybv10-2014-08-29-v1.3.1.dfu - Today, August 29
pybv10-2014-08-20-v1.3-22-g13ec400.dfu - August 20, before work on the gc
My results, not actually code but easier to make a simple table this way:
Code: Select all
Test: Old Runtime: New Runtime:
test_f1 10.480 sec 0.789 sec
test_f2 20.711 sec 1.235 sec
test_f3 20.664 sec 1.123 sec
test_cos1 23.137 sec 3.567 sec
test_cos2 33.277 sec 4.101 sec
There was only one run performed for each test, no averaging. Somehow, it didn't really seem necessary
