Issue 21644: Optimize bytearray(int) constructor to use calloc()

Python 3.5 has a new PyObject_Calloc() function which can be used for fast memory allocation of memory block initialized with zeros.

I already implemented an optimization, but Stefan Krah found issues in my change:
http://bugs.python.org/issue21233#msg217826

I reverted the optimization in the changeset dff6b4b61cac.

Stefan also wrote:

"3) Somewhat similarly, I wonder if it was necessary to refactor
   PyBytes_FromStringAndSize(). I find the new version more difficult
   to understand."

This issue can also be addressed here.

Stefan wrote:
"3) Somewhat similarly, I wonder if it was necessary to refactor
   PyBytes_FromStringAndSize(). I find the new version more difficult
   to understand."

Do you mean that the optimization is useless or that the implementation should be changed?

Responding to a comment in issue21233:

>    Before:
>    =======
>        >>> x = bytearray(0)
>        >>> m = memoryview(x)
>        >>> x.__init__(10)
>        Traceback (most recent call last):
>          File "<stdin>", line 1, in <module>
>        BufferError: Existing exports of data: object cannot be re-sized

I don't think such use cases are supported. Generally, reinitializing an 
object by calling __init__() explicitly is not well-defined, except when 
advertised explicitly in the documentation. The only property we should 
guarantee here is that it doesn't lead to an inconsistent object state, or to 
hard crashes. Raising an exception is fine, and changing the raised
exception to another one should be fine as well.

See also issue #22030 (set).

I'm not interested to work on this optimization, so I just close the issue.

Was this abandoned just because nobody had the time, or was there a problem with the approach? I independently wanted this optimisation, and have ended up implementing something very similar to what was reverted in https://hg.python.org/lookup/dff6b4b61cac.

In a benchmark that creates a large bytearray, then fills it with socket.readinto, I'm seeing a 2x performance improvement on Linux, and from some quick benchmarking it seems to be just as fast as the old code for small arrays that are allocated from the pool.

I abandonned the issue because I didn't have time to work on it. If you want, you can open a new issue for that.

> I abandonned the issue because I didn't have time to work on it. If you want, you can open a new issue for that.

If I make a pull request and run some microbenchmarks, will you (or some other core dev) have time to review it? I've had a bad experience before with a PR that I'm still unable to get reviewed after several years, so I'd like to get at least a tentative agreement before I invest time in it.