diff options
| author | Ulf Magnusson <ulfalizer@gmail.com> | 2017-09-21 19:07:47 +0200 |
|---|---|---|
| committer | Ulf Magnusson <ulfalizer@gmail.com> | 2017-09-21 20:21:00 +0200 |
| commit | 2de42031515a88d9847889e2d742b7066e33c26e (patch) | |
| tree | 6a008c7b98f200d6102bcebc063495efdefefd79 /README.md | |
| parent | 7b475ced7e38b0649e04940051a6438cbe4affd3 (diff) | |
Simplify expression representation
Store simple (<operator>, <operand 1>, <operand 2>) tuples instead of
(<operator>, [list of operands]) tuples.
The thought process behind the original representation was to avoid
creating lots of nodes for long X && Y && Z && ... chains that sometimes
appear, and possibly speed up evaluation. In retrospect, it's pretty
bad, for the following reasons:
1) _make_and() and _make_or() created lots of new merged lists instead
of simply reusing the tuples already allocated for the
subexpressions. This is slow and memory hungry.
2) Any gain in evaluating long expressions would barely offset slower
evaluation of short expressions.
3) The code became more complex.
Most importantly, this change makes expressions more straightforward to
work with for people peeking into internals.
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 3 |
1 files changed, 2 insertions, 1 deletions
@@ -100,7 +100,8 @@ to the test suite would make sense. ## Misc. notes ## * **Useful information can be extracted from internal data structures.** The - expression format is pretty simple for example (see the + expression format is pretty simple for example: `A && B && (!C || D == 3)` is + represented as (AND A (AND B (OR (NOT C) (EQUAL D 3)))); see the `Config._parse_expr()` docstring). It's hard to come up with good APIs for dealing with expressions given how |