Performance degradation after creating many classes with the same name #826
Description
I suspect this is heavily related to #575, but my analysis suggests the issues showed up in 19.2.0 (2019-10-01) and that issue was created before the release went live.
I made a simple test harness to demonstrate the issue:
def create_class():
@attr.s
class MyClass(object):
access_token = attr.ib()
expires = attr.ib()
refresh_token = attr.ib()
user = attr.ib()
return MyClass(
access_token="string",
expires=0,
refresh_token="string",
user="string",
)
%timeit create_class()
I ran this over attrs versions: 18.2, 19.1, 19.2, 20.1, 21.1, and 21.2.
I collected the outputs:
[
# Version num, timeit output, whether or not timeit warned for caching
(18.2, "358 µs ± 4.47 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)", False),
(19.1, "356 µs ± 1.8 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)", False),
(19.2, "22 ms ± 9.5 ms per loop (mean ± std. dev. of 7 runs, 1000 loops each)", "The slowest run took 4.71 times longer than the fastest"),
(20.1, "22.4 ms ± 9.85 ms per loop (mean ± std. dev. of 7 runs, 1000 loops each)", "The slowest run took 4.74 times longer than the fastest"),
(21.1, "22.9 ms ± 9.74 ms per loop (mean ± std. dev. of 7 runs, 1000 loops each)", "The slowest run took 5.12 times longer than the fastest"),
(21.2, "23.4 ms ± 10.5 ms per loop (mean ± std. dev. of 7 runs, 1000 loops each)", ""The slowest run took 4.91 times longer than the fastest"),
]
This suggests that something that went along with the 19.2 release is causing a performance leak. We noticed the issue because our CPU metrics started to spike when we upgraded attrs from version 18.2 directly to 21.2.