summaryrefslogtreecommitdiffstatshomepage
path: root/tests/bench
Commit message (Collapse)AuthorAge
* tests/bench: Add testcase to compare bytes(N) vs b"\0" * N.Paul Sokolovsky2016-06-08
| | | | Based on python-dev discussion regarding PEP467.
* tests: Update for _io/_collections module having been renamed.Paul Sokolovsky2016-05-02
|
* py: Use sequence of strings for named tuple initializationstijn2015-01-01
| | | | | | - 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.Paul Sokolovsky2014-06-19
|
* bench: Add test for map() vs inplace operations in array-likes.Paul Sokolovsky2014-06-19
| | | | | 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.Paul Sokolovsky2014-06-19
| | | | | | 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.Paul Sokolovsky2014-06-19
| | | | | For a trivial operation, calling a function is 5 times slower than doing operation inline.
* tests/bench: Add testcase for positional/kwargs to enumerate().Paul Sokolovsky2014-05-07
| | | | | 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.Paul Sokolovsky2014-05-07
| | | | | 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.Paul Sokolovsky2014-05-07
|
* tests/bench: Add testcases for lookup in 5-el instance and namedtuple.Paul Sokolovsky2014-05-07
| | | | | | | | | | | ... 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.Paul Sokolovsky2014-05-07
| | | | That's higher than instance field access - behold the power of hashing.
* tests/bench/var: Add tests for class/instance var access.Paul Sokolovsky2014-05-05
| | | | | Also compared with method abstraction for accessing instance vars - it's more than 3 times slower than accessing var directly.
* tests: Add framework for comparative benchmarking.Paul Sokolovsky2014-05-05
Motivation is optimizing handling of various constructs as well as understanding which constructs are more efficient in MicroPython. More info: http://forum.micropython.org/viewtopic.php?f=3&t=77 Results are wildly unexpected. For example, "optimization" of range iteration into while loop makes it twice as slow. Generally, the more bytecodes, the slower the code.
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-30 15:10:34 +0000