Odoo Changelog — 2020-04-03

Friday, April 3, 2020

2 changes · master

Improvements(2)

Enhancements to existing features

[IMP] core: remove odoo.tools.safe_eval._get_opcodes

Coremastercore

This update simplifies an internal code safety check by removing an outdated helper that is no longer needed with supported Python versions. It also makes the normal validation path slightly faster, improving core efficiency without changing user-facing behavior.

Original PR description

It's not necessary anymore as all supported Python versions implement
get_instructions, and inlining the usage of that is as readable as
calling _get_opcodes.

Also use the subset/superset predicate for validity testing instead of
difference as it's a fair bit faster:

    ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5))' 's2 - s1'
    5000000 loops, best of 5: 88.3 nsec per loop
    ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5, 15))' 's2 - s1'
    2000000 loops, best of 5: 159 nsec per loop
    ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5))' 's1 >= s2'
    5000000 loops, best of 5: 71.1 nsec per loop
    ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5, 15))' 's1 >= s2'
    5000000 loops, best of 5: 53.6 nsec per loop

we're paying double in the failure case but that doesn't super duper matter
because we're raising an exception and bailing out, the 24% gain on the
happy path seems more relevant.

#performance#maintenance#safe evaluation

[IMP] core: rebuild LRU on OrderedDict

PR #46061

Coremastercore

Odoo’s internal cache handling was simplified by using a standard Python component designed for this kind of work. This reduces maintenance complexity and may improve performance slightly without changing user-facing features.

Original PR description

OrderedDict exists largely for the purpose of writing LRUs and such (it's one of the reason OrderedDict is not and will never be an alias for the insertion-ordered dict).

Rebuilding LRU on OrderedDict:

* significantly reduces the amount of code even ignoring the removal of iteration
* might speed things up a bit (as CPython has a C implementation [since 3.5](https://bugs.python.org/issue16991))

Also removed the `iter*` methods: they're not used and they're not actually thread-safe as generator functions & methods immediately return when invoked, so the `@synchronized` only covers the creation of the generator not the actual iteration, they could be implemented safely by being completely eager (like `keys` was) or by using a proper context manager (but then I'm not quite sure what happens if we stop iterating before the end)

#performance#maintenance#cache

It's not necessary anymore as all supported Python versions implement get_instructions, and inlining the usage of that is as readable as calling _get_opcodes. Also use the subset/superset predicate for validity testing instead of difference as it's a fair bit faster: ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5))' 's2 - s1' 5000000 loops, best of 5: 88.3 nsec per loop ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5, 15))' 's2 - s1' 2000000 loops, best of 5: 159 nsec per loop ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5))' 's1 >= s2' 5000000 loops, best of 5: 71.1 nsec per loop ❯ python3.8 -mtimeit -s 's1 = set(range(10)); s2 = set(range(5, 15))' 's1 >= s2' 5000000 loops, best of 5: 53.6 nsec per loop we're paying double in the failure case but that doesn't super duper matter because we're raising an exception and bailing out, the 24% gain on the happy path seems more relevant.

OrderedDict exists largely for the purpose of writing LRUs and such (it's one of the reason OrderedDict is not and will never be an alias for the insertion-ordered dict). Rebuilding LRU on OrderedDict: * significantly reduces the amount of code even ignoring the removal of iteration * might speed things up a bit (as CPython has a C implementation [since 3.5](https://bugs.python.org/issue16991)) Also removed the `iter*` methods: they're not used and they're not actually thread-safe as generator functions & methods immediately return when invoked, so the `@synchronized` only covers the creation of the generator not the actual iteration, they could be implemented safely by being completely eager (like `keys` was) or by using a proper context manager (but then I'm not quite sure what happens if we stop iterating before the end)