[issue16389] re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench

mike bayer report at bugs.python.org
Sat Nov 3 15:31:41 CET 2012


mike bayer added the comment:

in response to ezio, I poked around the source here, since I've never been sure if re.compile() cached its result or not.   It seems to be the case in 2.7 and 3.2 also - 2.7 uses a local caching scheme and 3.2 uses functools.lru_cache, yet we don't see as much of a slowdown with 3.2.

so it seems like the caching behavior is precedent here, but I would revert re.py's caching scheme to the one used in 2.7 if the functools.lru_cache can't be sped up very significantly.  ideally lru_cache would be native.

also does python include any kind of benchmarking unit tests ?   over in SQLA we have an approach that fails if the call-counts of various functions, as measured by cProfile, fall outside of a known range.   it's caught many issues like these for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16389>
_______________________________________


More information about the Python-bugs-list mailing list