New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance issues with hashing attrs objects #261

Closed
DRMacIver opened this Issue Oct 7, 2017 · 15 comments

Comments

Projects
None yet
4 participants
@DRMacIver

DRMacIver commented Oct 7, 2017

Backstory: I got a bug about a performance regression reported in Hypothesis ( HypothesisWorks/hypothesis#919 ) and in the profiling data in the linked issue, the majority of the extra time (10 out of 13 seconds) is in attrs hashing.

This makes sense, as the enclosing method where most of the time is being spent does a lot of hashing of attrs objects, but it was still a bit surprising that it was this slow.

The class being hashed looks as follows:

@attr.s(slots=True, frozen=True)
class Arc(object):
    filename = attr.ib()
    source = attr.ib()
    target = attr.ib()

I have worked around this problem by now by removing attrs from this class and memoizing creation of it so that all value equal objects are reference equal, which is a bit more of an extreme solution than I expect attrs to support, but means that this bug is in no way critical for me as attrs will no longer be on the hot path of this code. It will probably however limit attrs uptake inside Hypothesis for now (I am likely to add a bunch more classes with a similar usage pattern and now will probably follow the pattern of the workaround I used here rather than using attrs).

The obvious two things that attrs could do to help are:

  • Have faster hashing. Almost all of that hashing time is in _attrs_to_tuple. Not creating these intermediate tuples (or creating them faster somehow) might be a significant win here.
  • Add support for caching the hash on the object. In my usage pattern the same objects were being hashed over and over again, and paying the hashing cost each time.
@Tinche

This comment has been minimized.

Member

Tinche commented Oct 7, 2017

Both of these are probably worth doing. Our hash methods are generic, that’s why they’re slow. It’s just that no one complained until now :) It’d be a rather straightforward change to generate a specialized hash for each class that would be more efficient.

Caching would be good too (as Hynek mentioned, frozen classes only), just need to figure out where to stash the cache.

@DRMacIver

This comment has been minimized.

DRMacIver commented Oct 7, 2017

Caching would be good too (as Hynek mentioned, frozen classes only), just need to figure out where to stash the cache.

FWIW the following is what I'd probably do (which you should feel to disregard as my design opinions are weird, but I feel like they're weird in a way that is very compatible with attrs):

  • Add a memoize_hash flag to attr.s defaulting to None.
  • When memoize_hash is True, store the hash on a field called __hash.
  • If hash is False (or inferred False from a default) it is an error to pass non-None memoize_hash
  • If slots and memoize_hash are both True, add a bonus __hash slot to the class to store it.
  • If hash is True, memoize_hash defaults to frozen and not slots
@hynek

This comment has been minimized.

Member

hynek commented Oct 7, 2017

I think I see another eval in our immediate future.

@hynek

This comment has been minimized.

Member

hynek commented Oct 7, 2017

I’m sitting in a car on a wine tour but I think I’d be OK with a simple specific eval-based implementation for 17.3. That should help already and should be straight-forward.

@DRMacIver

This comment has been minimized.

DRMacIver commented Oct 7, 2017

Our hash methods are generic, that’s why they’re slow. It’s just that no one complained until now :)

@DRMacIver in "Uses libraries in weird ways that nobody else has done before" shocker. 😉

@hynek

This comment has been minimized.

Member

hynek commented Oct 7, 2017

It might be the Chenin Blanc talking but isn’t hashing invoked whenever you put/get something into dicts and sets?

@DRMacIver

This comment has been minimized.

DRMacIver commented Oct 7, 2017

It is. The unusual thing about what I'm doing I think is key reuse and just how much I'm doing that.

@DRMacIver

This comment has been minimized.

DRMacIver commented Oct 7, 2017

I was in the process of profiling the code for the Hypothesis issue and I noticed that I'm also seeing attrs's generated equality methods in the profile code. This is also using attrs_to_tuple. If you're going to be doing an eval to get hash, __eq__ should probably come along for the ride.

@DRMacIver

This comment has been minimized.

DRMacIver commented Oct 8, 2017

While I'm giving you a wishlist (sorry 😉), I note that the equality generated by attrs doesn't start with an is check. i.e. it would be much faster if it began with if self is other: return True.

The big problem with adding this is that it changes the semantics in the presence of e.g. NaN. Previously x = Foo(float('nan')); x == x would be False, and adding a reference equal check would make it True. Would you be OK with that change?

@DRMacIver

This comment has been minimized.

DRMacIver commented Oct 8, 2017

I note that the equality generated by attrs doesn't start with an is check

I have however also remembered that this is irrelevant for collection performance because the semantics of getitem/setitem/etc bypass equality for reference equal values. So maybe a separate concern.

@hynek

This comment has been minimized.

Member

hynek commented Dec 30, 2017

Did the situation improve as of attrs 17.4 @DRMacIver?

bors-fusion bot added a commit to fusionapp/documint that referenced this issue Jan 1, 2018

Merge #124
124: Scheduled weekly dependency update for week 00 r=mithrandi a=pyup-bot




## Updates
Here's a list of all the updates bundled in this pull request. I've added some links to make it easier for you to find all the information you need.
<table align="center">

<tr>
<td><b>asn1crypto</b></td>
<td align="center">0.23.0</td>
<td align="center">&raquo;</td>
<td align="center">0.24.0</td>
<td>
     <a href="https://pypi.python.org/pypi/asn1crypto">PyPI</a> | <a href="https://pyup.io/changelogs/asn1crypto/">Changelog</a> | <a href="https://github.com/wbond/asn1crypto/issues">Repo</a> 

</td>

<tr>
<td><b>attrs</b></td>
<td align="center">17.3.0</td>
<td align="center">&raquo;</td>
<td align="center">17.4.0</td>
<td>
     <a href="https://pypi.python.org/pypi/attrs">PyPI</a> | <a href="https://pyup.io/changelogs/attrs/">Changelog</a> | <a href="http://www.attrs.org/">Homepage</a> 

</td>

<tr>
<td><b>ipaddress</b></td>
<td align="center">1.0.18</td>
<td align="center">&raquo;</td>
<td align="center">1.0.19</td>
<td>
     <a href="https://pypi.python.org/pypi/ipaddress">PyPI</a> | <a href="https://github.com/phihag/ipaddress">Repo</a> 

</td>

</tr>
</table>



## Changelogs


### asn1crypto 0.23.0 -> 0.24.0

>### 0.24.0


> - `x509.Certificate().self_signed` will no longer return `&quot;yes&quot;` under any
>   circumstances. This helps prevent confusion since the library does not
>   verify the signature. Instead a library like oscrypto should be used
>   to confirm if a certificate is self-signed.
> - Added various OIDs to `x509.KeyPurposeId()`
> - Added `x509.Certificate().private_key_usage_period_value`
> - Added structures for parsing common subject directory attributes for
>   X.509 certificates, including `x509.SubjectDirectoryAttribute()`
> - Added `algos.AnyAlgorithmIdentifier()` for situations where an
>   algorithm identifier may contain a digest, signed digest or encryption
>   algorithm OID
> - Fixed a bug with `x509.Certificate().subject_directory_attributes_value`
>   not returning the correct value
> - Fixed a bug where explicitly-tagged fields in a `core.Sequence()` would
>   not function properly when the field had a default value
> - Fixed a bug with type checking in `pem.armor()`







### attrs 17.3.0 -> 17.4.0

>### 17.4.0

>-------------------

>Backward-incompatible Changes
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>- The traversal of MROs when using multiple inheritance was backward:
>  If you defined a class ``C`` that subclasses ``A`` and ``B`` like ``C(A, B)``, ``attrs`` would have collected the attributes from ``B`` *before* those of ``A``.

>  This is now fixed and means that in classes that employ multiple inheritance, the output of ``__repr__`` and the order of positional arguments in ``__init__`` changes.
>  Due to the nature of this bug, a proper deprecation cycle was unfortunately impossible.

>  Generally speaking, it&#39;s advisable to prefer ``kwargs``-based initialization anyways – *especially* if you employ multiple inheritance and diamond-shaped hierarchies.

>  `298 &lt;https://github.com/python-attrs/attrs/issues/298&gt;`_,
>  `299 &lt;https://github.com/python-attrs/attrs/issues/299&gt;`_,
>  `304 &lt;https://github.com/python-attrs/attrs/issues/304&gt;`_
>- The ``__repr__`` set by ``attrs``
>  no longer produces an ``AttributeError``
>  when the instance is missing some of the specified attributes
>  (either through deleting
>  or after using ``init=False`` on some attributes).

>  This can break code
>  that relied on ``repr(attr_cls_instance)`` raising ``AttributeError``
>  to check if any attr-specified members were unset.

>  If you were using this,
>  you can implement a custom method for checking this::

>      def has_unset_members(self):
>          for field in attr.fields(type(self)):
>              try:
>                  getattr(self, field.name)
>              except AttributeError:
>                  return True
>          return False

>  `308 &lt;https://github.com/python-attrs/attrs/issues/308&gt;`_


>Deprecations
>^^^^^^^^^^^^

>- The ``attr.ib(convert=callable)`` option is now deprecated in favor of ``attr.ib(converter=callable)``.

>  This is done to achieve consistency with other noun-based arguments like *validator*.

>  *convert* will keep working until at least January 2019 while raising a ``DeprecationWarning``.

>  `307 &lt;https://github.com/python-attrs/attrs/issues/307&gt;`_


>Changes
>^^^^^^^

>- Generated ``__hash__`` methods now hash the class type along with the attribute values.
>  Until now the hashes of two classes with the same values were identical which was a bug.

>  The generated method is also *much* faster now.

>  `261 &lt;https://github.com/python-attrs/attrs/issues/261&gt;`_,
>  `295 &lt;https://github.com/python-attrs/attrs/issues/295&gt;`_,
>  `296 &lt;https://github.com/python-attrs/attrs/issues/296&gt;`_
>- ``attr.ib``\ ’s ``metadata`` argument now defaults to a unique empty ``dict`` instance instead of sharing a common empty ``dict`` for all.
>  The singleton empty ``dict`` is still enforced.

>  `280 &lt;https://github.com/python-attrs/attrs/issues/280&gt;`_
>- ``ctypes`` is optional now however if it&#39;s missing, a bare ``super()`` will not work in slots classes.
>  This should only happen in special environments like Google App Engine.

>  `284 &lt;https://github.com/python-attrs/attrs/issues/284&gt;`_,
>  `286 &lt;https://github.com/python-attrs/attrs/issues/286&gt;`_
>- The attribute redefinition feature introduced in 17.3.0 now takes into account if an attribute is redefined via multiple inheritance.
>  In that case, the definition that is closer to the base of the class hierarchy wins.

>  `285 &lt;https://github.com/python-attrs/attrs/issues/285&gt;`_,
>  `287 &lt;https://github.com/python-attrs/attrs/issues/287&gt;`_
>- Subclasses of ``auto_attribs=True`` can be empty now.

>  `291 &lt;https://github.com/python-attrs/attrs/issues/291&gt;`_,
>  `292 &lt;https://github.com/python-attrs/attrs/issues/292&gt;`_
>- Equality tests are *much* faster now.

>  `306 &lt;https://github.com/python-attrs/attrs/issues/306&gt;`_
>- All generated methods now have correct ``__module__``, ``__name__``, and (on Python 3) ``__qualname__`` attributes.

>  `309 &lt;https://github.com/python-attrs/attrs/issues/309&gt;`_


>----











That's it for now!

Happy merging! 🤖

bors-fusion bot added a commit to fusionapp/entropy that referenced this issue Jan 1, 2018

Merge #167
167: Scheduled weekly dependency update for week 00 r=mithrandi a=pyup-bot




## Updates
Here's a list of all the updates bundled in this pull request. I've added some links to make it easier for you to find all the information you need.
<table align="center">

<tr>
<td><b>asn1crypto</b></td>
<td align="center">0.23.0</td>
<td align="center">&raquo;</td>
<td align="center">0.24.0</td>
<td>
     <a href="https://pypi.python.org/pypi/asn1crypto">PyPI</a> | <a href="https://pyup.io/changelogs/asn1crypto/">Changelog</a> | <a href="https://github.com/wbond/asn1crypto/issues">Repo</a> 

</td>

<tr>
<td><b>attrs</b></td>
<td align="center">17.3.0</td>
<td align="center">&raquo;</td>
<td align="center">17.4.0</td>
<td>
     <a href="https://pypi.python.org/pypi/attrs">PyPI</a> | <a href="https://pyup.io/changelogs/attrs/">Changelog</a> | <a href="http://www.attrs.org/">Homepage</a> 

</td>

<tr>
<td><b>ipaddress</b></td>
<td align="center">1.0.18</td>
<td align="center">&raquo;</td>
<td align="center">1.0.19</td>
<td>
     <a href="https://pypi.python.org/pypi/ipaddress">PyPI</a> | <a href="https://github.com/phihag/ipaddress">Repo</a> 

</td>

<tr>
<td><b>txaws</b></td>
<td align="center">0.4.0</td>
<td align="center">&raquo;</td>
<td align="center">0.5.0</td>
<td>
     <a href="https://pypi.python.org/pypi/txaws">PyPI</a> | <a href="https://pyup.io/changelogs/txaws/">Changelog</a> | <a href="https://github.com/twisted/txaws">Repo</a> 

</td>

</tr>
</table>



## Changelogs


### asn1crypto 0.23.0 -> 0.24.0

>### 0.24.0


> - `x509.Certificate().self_signed` will no longer return `&quot;yes&quot;` under any
>   circumstances. This helps prevent confusion since the library does not
>   verify the signature. Instead a library like oscrypto should be used
>   to confirm if a certificate is self-signed.
> - Added various OIDs to `x509.KeyPurposeId()`
> - Added `x509.Certificate().private_key_usage_period_value`
> - Added structures for parsing common subject directory attributes for
>   X.509 certificates, including `x509.SubjectDirectoryAttribute()`
> - Added `algos.AnyAlgorithmIdentifier()` for situations where an
>   algorithm identifier may contain a digest, signed digest or encryption
>   algorithm OID
> - Fixed a bug with `x509.Certificate().subject_directory_attributes_value`
>   not returning the correct value
> - Fixed a bug where explicitly-tagged fields in a `core.Sequence()` would
>   not function properly when the field had a default value
> - Fixed a bug with type checking in `pem.armor()`







### attrs 17.3.0 -> 17.4.0

>### 17.4.0

>-------------------

>Backward-incompatible Changes
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>- The traversal of MROs when using multiple inheritance was backward:
>  If you defined a class ``C`` that subclasses ``A`` and ``B`` like ``C(A, B)``, ``attrs`` would have collected the attributes from ``B`` *before* those of ``A``.

>  This is now fixed and means that in classes that employ multiple inheritance, the output of ``__repr__`` and the order of positional arguments in ``__init__`` changes.
>  Due to the nature of this bug, a proper deprecation cycle was unfortunately impossible.

>  Generally speaking, it&#39;s advisable to prefer ``kwargs``-based initialization anyways – *especially* if you employ multiple inheritance and diamond-shaped hierarchies.

>  `298 &lt;https://github.com/python-attrs/attrs/issues/298&gt;`_,
>  `299 &lt;https://github.com/python-attrs/attrs/issues/299&gt;`_,
>  `304 &lt;https://github.com/python-attrs/attrs/issues/304&gt;`_
>- The ``__repr__`` set by ``attrs``
>  no longer produces an ``AttributeError``
>  when the instance is missing some of the specified attributes
>  (either through deleting
>  or after using ``init=False`` on some attributes).

>  This can break code
>  that relied on ``repr(attr_cls_instance)`` raising ``AttributeError``
>  to check if any attr-specified members were unset.

>  If you were using this,
>  you can implement a custom method for checking this::

>      def has_unset_members(self):
>          for field in attr.fields(type(self)):
>              try:
>                  getattr(self, field.name)
>              except AttributeError:
>                  return True
>          return False

>  `308 &lt;https://github.com/python-attrs/attrs/issues/308&gt;`_


>Deprecations
>^^^^^^^^^^^^

>- The ``attr.ib(convert=callable)`` option is now deprecated in favor of ``attr.ib(converter=callable)``.

>  This is done to achieve consistency with other noun-based arguments like *validator*.

>  *convert* will keep working until at least January 2019 while raising a ``DeprecationWarning``.

>  `307 &lt;https://github.com/python-attrs/attrs/issues/307&gt;`_


>Changes
>^^^^^^^

>- Generated ``__hash__`` methods now hash the class type along with the attribute values.
>  Until now the hashes of two classes with the same values were identical which was a bug.

>  The generated method is also *much* faster now.

>  `261 &lt;https://github.com/python-attrs/attrs/issues/261&gt;`_,
>  `295 &lt;https://github.com/python-attrs/attrs/issues/295&gt;`_,
>  `296 &lt;https://github.com/python-attrs/attrs/issues/296&gt;`_
>- ``attr.ib``\ ’s ``metadata`` argument now defaults to a unique empty ``dict`` instance instead of sharing a common empty ``dict`` for all.
>  The singleton empty ``dict`` is still enforced.

>  `280 &lt;https://github.com/python-attrs/attrs/issues/280&gt;`_
>- ``ctypes`` is optional now however if it&#39;s missing, a bare ``super()`` will not work in slots classes.
>  This should only happen in special environments like Google App Engine.

>  `284 &lt;https://github.com/python-attrs/attrs/issues/284&gt;`_,
>  `286 &lt;https://github.com/python-attrs/attrs/issues/286&gt;`_
>- The attribute redefinition feature introduced in 17.3.0 now takes into account if an attribute is redefined via multiple inheritance.
>  In that case, the definition that is closer to the base of the class hierarchy wins.

>  `285 &lt;https://github.com/python-attrs/attrs/issues/285&gt;`_,
>  `287 &lt;https://github.com/python-attrs/attrs/issues/287&gt;`_
>- Subclasses of ``auto_attribs=True`` can be empty now.

>  `291 &lt;https://github.com/python-attrs/attrs/issues/291&gt;`_,
>  `292 &lt;https://github.com/python-attrs/attrs/issues/292&gt;`_
>- Equality tests are *much* faster now.

>  `306 &lt;https://github.com/python-attrs/attrs/issues/306&gt;`_
>- All generated methods now have correct ``__module__``, ``__name__``, and (on Python 3) ``__qualname__`` attributes.

>  `309 &lt;https://github.com/python-attrs/attrs/issues/309&gt;`_


>----











That's it for now!

Happy merging! 🤖

bors-fusion bot added a commit to fusionapp/fusion-index that referenced this issue Jan 1, 2018

Merge #174
174: Scheduled weekly dependency update for week 00 r=mithrandi a=pyup-bot




## Updates
Here's a list of all the updates bundled in this pull request. I've added some links to make it easier for you to find all the information you need.
<table align="center">

<tr>
<td><b>asn1crypto</b></td>
<td align="center">0.23.0</td>
<td align="center">&raquo;</td>
<td align="center">0.24.0</td>
<td>
     <a href="https://pypi.python.org/pypi/asn1crypto">PyPI</a> | <a href="https://pyup.io/changelogs/asn1crypto/">Changelog</a> | <a href="https://github.com/wbond/asn1crypto/issues">Repo</a> 

</td>

<tr>
<td><b>attrs</b></td>
<td align="center">17.3.0</td>
<td align="center">&raquo;</td>
<td align="center">17.4.0</td>
<td>
     <a href="https://pypi.python.org/pypi/attrs">PyPI</a> | <a href="https://pyup.io/changelogs/attrs/">Changelog</a> | <a href="http://www.attrs.org/">Homepage</a> 

</td>

<tr>
<td><b>hypothesis</b></td>
<td align="center">3.40.1</td>
<td align="center">&raquo;</td>
<td align="center">3.44.4</td>
<td>
     <a href="https://pypi.python.org/pypi/hypothesis">PyPI</a> | <a href="https://pyup.io/changelogs/hypothesis/">Changelog</a> | <a href="https://github.com/HypothesisWorks/hypothesis/issues">Repo</a> 

</td>

<tr>
<td><b>ipaddress</b></td>
<td align="center">1.0.18</td>
<td align="center">&raquo;</td>
<td align="center">1.0.19</td>
<td>
     <a href="https://pypi.python.org/pypi/ipaddress">PyPI</a> | <a href="https://github.com/phihag/ipaddress">Repo</a> 

</td>

<tr>
<td><b>pyrsistent</b></td>
<td align="center">0.14.1</td>
<td align="center">&raquo;</td>
<td align="center">0.14.2</td>
<td>
     <a href="https://pypi.python.org/pypi/pyrsistent">PyPI</a> | <a href="https://pyup.io/changelogs/pyrsistent/">Changelog</a> | <a href="http://github.com/tobgu/pyrsistent/">Repo</a> 

</td>

<tr>
<td><b>toolz</b></td>
<td align="center">0.8.2</td>
<td align="center">&raquo;</td>
<td align="center">0.9.0</td>
<td>
     <a href="https://pypi.python.org/pypi/toolz">PyPI</a> | <a href="https://github.com/pytoolz/toolz">Repo</a> 

</td>

</tr>
</table>



## Changelogs


### asn1crypto 0.23.0 -> 0.24.0

>### 0.24.0


> - `x509.Certificate().self_signed` will no longer return `&quot;yes&quot;` under any
>   circumstances. This helps prevent confusion since the library does not
>   verify the signature. Instead a library like oscrypto should be used
>   to confirm if a certificate is self-signed.
> - Added various OIDs to `x509.KeyPurposeId()`
> - Added `x509.Certificate().private_key_usage_period_value`
> - Added structures for parsing common subject directory attributes for
>   X.509 certificates, including `x509.SubjectDirectoryAttribute()`
> - Added `algos.AnyAlgorithmIdentifier()` for situations where an
>   algorithm identifier may contain a digest, signed digest or encryption
>   algorithm OID
> - Fixed a bug with `x509.Certificate().subject_directory_attributes_value`
>   not returning the correct value
> - Fixed a bug where explicitly-tagged fields in a `core.Sequence()` would
>   not function properly when the field had a default value
> - Fixed a bug with type checking in `pem.armor()`







### attrs 17.3.0 -> 17.4.0

>### 17.4.0

>-------------------

>Backward-incompatible Changes
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>- The traversal of MROs when using multiple inheritance was backward:
>  If you defined a class ``C`` that subclasses ``A`` and ``B`` like ``C(A, B)``, ``attrs`` would have collected the attributes from ``B`` *before* those of ``A``.

>  This is now fixed and means that in classes that employ multiple inheritance, the output of ``__repr__`` and the order of positional arguments in ``__init__`` changes.
>  Due to the nature of this bug, a proper deprecation cycle was unfortunately impossible.

>  Generally speaking, it&#39;s advisable to prefer ``kwargs``-based initialization anyways – *especially* if you employ multiple inheritance and diamond-shaped hierarchies.

>  `298 &lt;https://github.com/python-attrs/attrs/issues/298&gt;`_,
>  `299 &lt;https://github.com/python-attrs/attrs/issues/299&gt;`_,
>  `304 &lt;https://github.com/python-attrs/attrs/issues/304&gt;`_
>- The ``__repr__`` set by ``attrs``
>  no longer produces an ``AttributeError``
>  when the instance is missing some of the specified attributes
>  (either through deleting
>  or after using ``init=False`` on some attributes).

>  This can break code
>  that relied on ``repr(attr_cls_instance)`` raising ``AttributeError``
>  to check if any attr-specified members were unset.

>  If you were using this,
>  you can implement a custom method for checking this::

>      def has_unset_members(self):
>          for field in attr.fields(type(self)):
>              try:
>                  getattr(self, field.name)
>              except AttributeError:
>                  return True
>          return False

>  `308 &lt;https://github.com/python-attrs/attrs/issues/308&gt;`_


>Deprecations
>^^^^^^^^^^^^

>- The ``attr.ib(convert=callable)`` option is now deprecated in favor of ``attr.ib(converter=callable)``.

>  This is done to achieve consistency with other noun-based arguments like *validator*.

>  *convert* will keep working until at least January 2019 while raising a ``DeprecationWarning``.

>  `307 &lt;https://github.com/python-attrs/attrs/issues/307&gt;`_


>Changes
>^^^^^^^

>- Generated ``__hash__`` methods now hash the class type along with the attribute values.
>  Until now the hashes of two classes with the same values were identical which was a bug.

>  The generated method is also *much* faster now.

>  `261 &lt;https://github.com/python-attrs/attrs/issues/261&gt;`_,
>  `295 &lt;https://github.com/python-attrs/attrs/issues/295&gt;`_,
>  `296 &lt;https://github.com/python-attrs/attrs/issues/296&gt;`_
>- ``attr.ib``\ ’s ``metadata`` argument now defaults to a unique empty ``dict`` instance instead of sharing a common empty ``dict`` for all.
>  The singleton empty ``dict`` is still enforced.

>  `280 &lt;https://github.com/python-attrs/attrs/issues/280&gt;`_
>- ``ctypes`` is optional now however if it&#39;s missing, a bare ``super()`` will not work in slots classes.
>  This should only happen in special environments like Google App Engine.

>  `284 &lt;https://github.com/python-attrs/attrs/issues/284&gt;`_,
>  `286 &lt;https://github.com/python-attrs/attrs/issues/286&gt;`_
>- The attribute redefinition feature introduced in 17.3.0 now takes into account if an attribute is redefined via multiple inheritance.
>  In that case, the definition that is closer to the base of the class hierarchy wins.

>  `285 &lt;https://github.com/python-attrs/attrs/issues/285&gt;`_,
>  `287 &lt;https://github.com/python-attrs/attrs/issues/287&gt;`_
>- Subclasses of ``auto_attribs=True`` can be empty now.

>  `291 &lt;https://github.com/python-attrs/attrs/issues/291&gt;`_,
>  `292 &lt;https://github.com/python-attrs/attrs/issues/292&gt;`_
>- Equality tests are *much* faster now.

>  `306 &lt;https://github.com/python-attrs/attrs/issues/306&gt;`_
>- All generated methods now have correct ``__module__``, ``__name__``, and (on Python 3) ``__qualname__`` attributes.

>  `309 &lt;https://github.com/python-attrs/attrs/issues/309&gt;`_


>----








### hypothesis 3.40.1 -> 3.44.4

>### 3.44.4

>-------------------

>This release fixes :issue:`1044`, which slowed tests by up to 6%
>due to broken caching.

>-------------------


>### 3.44.3

>-------------------

>This release improves the shrinker in cases where examples drawn earlier can
>affect how much data is drawn later (e.g. when you draw a length parameter in
>a composite and then draw that many elements). Examples found in cases like
>this should now be much closer to minimal.

>-------------------


>### 3.44.2

>-------------------

>This is a pure refactoring release which changes how Hypothesis manages its
>set of examples internally. It should have no externally visible effects.

>-------------------


>### 3.44.1

>-------------------

>This release fixes :issue:`997`, in which under some circumstances the body of
>tests run under Hypothesis would not show up when run under coverage even
>though the tests were run and the code they called outside of the test file
>would show up normally.

>-------------------


>### 3.44.0

>-------------------

>This release adds a new feature: The :ref:`reproduce_failure &lt;reproduce_failure&gt;`,
>designed to make it easy to use Hypothesis&#39;s binary format for examples to
>reproduce a problem locally without having to share your example database
>between machines.

>This also changes when seeds are printed:

>* They will no longer be printed for
>  normal falsifying examples, as there are now adequate ways of reproducing those
>  for all cases, so it just contributes noise.
>* They will once again be printed when reusing examples from the database, as
>  health check failures should now be more reliable in this scenario so it will
>  almost always work in this case.

>This work was funded by `Smarkets &lt;https://smarkets.com/&gt;`_.

>-------------------


>### 3.43.1

>-------------------

>This release fixes a bug with Hypothesis&#39;s database management - examples that
>were found in the course of shrinking were saved in a way that indicated that
>they had distinct causes, and so they would all be retried on the start of the
>next test. The intended behaviour, which is now what is implemented, is that
>only a bounded subset of these examples would be retried.

>-------------------


>### 3.43.0

>-------------------

>:exc:`~hypothesis.errors.HypothesisDeprecationWarning` now inherits from
>:exc:`python:FutureWarning` instead of :exc:`python:DeprecationWarning`,
>as recommended by :pep:`565` for user-facing warnings (:issue:`618`).
>If you have not changed the default warnings settings, you will now see
>each distinct :exc:`~hypothesis.errors.HypothesisDeprecationWarning`
>instead of only the first.

>-------------------


>### 3.42.2

>-------------------

>This patch fixes :issue:`1017`, where instances of a list or tuple subtype
>used as an argument to a strategy would be coerced to tuple.

>-------------------


>### 3.42.1

>-------------------

>This release has some internal cleanup, which makes reading the code
>more pleasant and may shrink large examples slightly faster.

>-------------------


>### 3.42.0

>-------------------

>This release deprecates :ref:`faker-extra`, which was designed as a transition
>strategy but does not support example shrinking or coverage-guided discovery.

>-------------------


>### 3.41.0

>-------------------

>:func:`~hypothesis.strategies.sampled_from` can now sample from
>one-dimensional numpy ndarrays. Sampling from multi-dimensional
>ndarrays still results in a deprecation warning. Thanks to Charlie
>Tanksley for this patch.

>-------------------






### pyrsistent 0.14.1 -> 0.14.2

>### 0.14.2

> * Fix 121, regression in PClass.set() introduced in 0.14.1.










That's it for now!

Happy merging! 🤖
@mr-nfamous

This comment has been minimized.

mr-nfamous commented Jan 22, 2018

No idea how to contribute to projects so I'll just post here my solution that makes _make_hash 3x faster:

def _make_hash(attrs):
    attrs = tuple(
        a
        for a in attrs
        if a.hash is True or (a.hash is None and a.cmp is True)
    )
 
    attrs_getter = attrgetter(*map(attrgetter('name'), attrs))
    def hash_(self):
        """
        Automatically created by attrs.
        """
        return hash(attrs_getter(self))
 
    return hash_

@hynek

This comment has been minimized.

Member

hynek commented Jan 22, 2018

Did you benchmark it against the current (17.4.0) implementation? We generate code like for __init__ now so I’d be surprised if an attrsgetter-based approach is 3x faster; or faster at all.

@hynek

This comment has been minimized.

Member

hynek commented Feb 1, 2018

I’m gonna interpret the lack of feedback as that the issue is at least roughly resolved.

@hynek hynek closed this Feb 1, 2018

@DRMacIver

This comment has been minimized.

DRMacIver commented Feb 1, 2018

I’m gonna interpret the lack of feedback as that the issue is at least roughly resolved.

Sorry about that. I don't have a convenient way to benchmark this as I ended up taking all of this code down a different route where it no longer really makes sense as an attrs benchmark. If you consider it fixed I'm happy, as I'm no longer affected by it either way, and if I run into problems here in future I'll reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment