suspect-devices/circuitpython/tests/bench, branch v1.5.1 CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=v1.5.1 2015-01-01T12:53:23+00:00 py: Use sequence of strings for named tuple initialization 2015-01-01T12:53:23+00:00 stijn stinos@zoho.com 2014-12-20T15:37:40+00:00 urn:sha1:12340147b0ace7c1feeaf36b618c92652bdb849f - remove single string initialization style - take list of strings instead - store list in the type for fast lookup bench: Three ways to process a byte buffer. 2014-06-19T19:27:13+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-06-19T19:27:13+00:00 urn:sha1:74c710187c77ebd5ab8c5a44b07087f2c2ca786e bench: Add test for map() vs inplace operations in array-likes. 2014-06-19T19:19:24+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-06-19T18:54:51+00:00 urn:sha1:59ced651b542941f893293099a932252e498eb7c map() is 5 times slower. That's mostly because of inefficiency of creating containers from iterables of unknown length (like map()). bench: Add tests for constructing various containers from iterator. 2014-06-19T18:44:33+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-06-19T18:44:33+00:00 urn:sha1:17db09650569609793061e83aded7039e39e81a7 Both "bound" (like, length known) and "unbound" (length unknown) are tested. All of list, tuple, bytes, bytesarray offer approximately the same performance, with "unbound" case being 30 times slower. bench: Add test for function call overhead. 2014-06-19T17:49:03+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-06-19T00:20:34+00:00 urn:sha1:e53d2197e4a749b2e2265c7b42f9b9834128799f For a trivial operation, calling a function is 5 times slower than doing operation inline. tests/bench: Add testcase for positional/kwargs to enumerate(). 2014-05-07T19:34:06+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-05-07T19:07:10+00:00 urn:sha1:69cbec4afb3ac191334f0cfc5bfa14b2cdefea4c Inspired by discussion in #577. So, in this case of builtin function, passing args by keyword has less than 1% overhead. tests/bench: Add tests for various ways to pass function args. 2014-05-07T19:34:04+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-05-07T18:39:09+00:00 urn:sha1:2a05f05f4468bc937e412e94df75da9dce9a6148 Passing 3 args with keywords is for example 50% slower than via positional args. tests/bench: Add variation on loop_count/while_down_ne test. 2014-05-07T19:34:04+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-05-07T18:38:13+00:00 urn:sha1:169515126784425df7b6fcd0a78ee5eb7dd84788 tests/bench: Add testcases for lookup in 5-el instance and namedtuple. 2014-05-07T19:34:00+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-05-07T18:33:36+00:00 urn:sha1:6638ea9ca37377a8136fb25f64f7c7710f641cd2 ... and we have not that bad mapping type after all - lookup time is ~ the same as in one-attr instance. My namedtuple implementation on the other hand degrades awfully. So, need to rework it. First observation is that named tuple fields are accessed as attributes, so all names are interned at the program start. Then, really should store field array as qstr[], and do quick 32/64 bit scan thru it. tests/bench: Time namedtuple field access. 2014-05-07T19:33:37+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2014-05-07T15:14:48+00:00 urn:sha1:52b25293e2bc7aa6828039c4535916f165031659 That's higher than instance field access - behold the power of hashing.