classification
Title: Optimize BytesIO to do less reallocations when written, similarly to StringIO
Type: performance Stage: patch review
Components: Library (Lib) Versions: Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: Arfrever, BreamoreBoy, benjamin.peterson, berker.peksag, dw, eli.bendersky, hynek, jcon, kmike, meador.inge, ncoghlan, pitrou, python-dev, scoder, serhiy.storchaka, stutzbach, tshepang, vstinner
Priority: normal Keywords: patch

Created on 2012-07-17 12:12 by eli.bendersky, last changed 2015-02-14 23:44 by BreamoreBoy.

Files
File name Uploaded Description Edit
bytesio_resized_bytes-2.patch serhiy.storchaka, 2012-07-20 20:30 review
bytesio_resized_bytes-3.patch serhiy.storchaka, 2013-11-07 17:33 review
bytesio_resized_bytes-4.patch serhiy.storchaka, 2014-07-31 15:00 review
bytesio_faster_readline.patch serhiy.storchaka, 2014-08-14 10:29 review
bytesio_resized_bytes-5.patch serhiy.storchaka, 2014-08-14 20:05 review
bytesio_resized_bytes-6.patch serhiy.storchaka, 2015-01-31 12:23 review
Messages (47)
msg165715 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-07-17 12:12
From this pydev thread: http://mail.python.org/pipermail/python-dev/2012-July/120981.html

"BytesIO is actually missing an optimisation that is already used in
StringIO: the StringIO C implementation uses a fragment accumulator
internally, and collapses that into a single string object when
getvalue() is called. BytesIO is still using the old
"resize-the-buffer-as-you-go" strategy, and thus ends up repeatedly
reallocating the buffer as the data sequence grows incrementally.

It should be optimised to work the same way StringIO does (which is
effectively the same way that the monkeypatched version works)"
msg165716 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-07-17 12:49
This optimization for StringIO was done in issue #13149
msg165718 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-17 13:26
I am not see that BytesIO is slower than StringIO (both are about 30% slower than append/join).

$ ./python -m timeit -s "import io; d=[b'a'*10,b'bb'*5,b'ccc'*5]*1000"  "b=[]; w=b.append"  "for x in d: w(x)"  "b''.join(b)"
1000 loops, best of 3: 966 usec per loop

$ ./python -m timeit -s "import io; d=['a'*10,'bb'*5,'ccc'*5]*1000"  "b=[]; w=b.append"  "for x in d: w(x)"  "''.join(b)"
1000 loops, best of 3: 918 usec per loop

$ ./python -m timeit -s "import io; d=[b'a'*10,b'bb'*5,b'ccc'*5]*1000"  "b=io.BytesIO(); w=b.write"  "for x in d: w(x)"  "b.getvalue()"
1000 loops, best of 3: 1.22 msec per loop

$ ./python -m timeit -s "import io; d=['a'*10,'bb'*5,'ccc'*5]*1000"  "b=io.StringIO(); w=b.write"  "for x in d: w(x)"  "b.getvalue()"
1000 loops, best of 3: 1.24 msec per loop
msg165748 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-07-18 09:32
I wonder if this is a fair comparison, Serhiy. Strings are unicode underneath, so they have a large overhead per string (more data to copy around). Increasing the length of the strings changes the game because due to PEP 393, the overhead for ASCII-only Unicode strings is constant:

>>> import sys
>>> sys.getsizeof('a')
50
>>> sys.getsizeof(b'a')
34
>>> sys.getsizeof('a' * 1000)
1049
>>> sys.getsizeof(b'a' * 1000)
1033
>>> 

When re-running your tests with larger chunks, the results are quite interesting:

$ ./python -m timeit -s "import io; d=[b'a'*100,b'bb'*50,b'ccc'*50]*1000"  "b=io.BytesIO(); w=b.write"  "for x in d: w(x)"  "b.getvalue()"
1000 loops, best of 3: 509 usec per loop
$ ./python -m timeit -s "import io; d=['a'*100,'bb'*50,'ccc'*50]*1000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
1000 loops, best of 3: 282 usec per loop

So, it seems to me that BytesIO could use some optimization!
msg165760 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-07-18 11:58
I'd like to take a shot at this, if Antoine doesn't mind. I'll prepare a patch for bytesio.c

Question: what set of benchmarks would it be good to run to make sure this doesn't degrade the performance of BytesIO in various cases?
msg165780 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-18 14:29
> I wonder if this is a fair comparison, Serhiy.

I just used your examples.

> When re-running your tests with larger chunks, the results are quite interesting:

Well, now I see, that BytesIO slower StringIO.
msg165795 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-18 20:06
Here is a preliminary version of the patch. I am not sure that it is fully correct.

Microbenchmark results:

$ ./python -m timeit -s "import io; n=100; d=['a'*n,'bb'*n,'ccc'*n]*10000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 25.5 msec per loop
$ ./python -m timeit -s "import io; n=100; d=[b'a'*n,b'bb'*n,b'ccc'*n]*10000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 39.9 msec per loop
$ ./python-patched -m timeit -s "import io; n=100; d=[b'a'*n,b'bb'*n,b'ccc'*n]*10000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 26.1 msec per loop

$ ./python -m timeit -s "import io; n=1000; d=['a'*n,'bb'*n,'ccc'*n]*1000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
100 loops, best of 3: 12.1 msec per loop
$ ./python -m timeit -s "import io; n=1000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
10 loops, best of 3: 26.5 msec per loop
$ ./python-patched -m timeit -s "import io; n=1000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
100 loops, best of 3: 13.6 msec per loop
msg165883 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-19 22:04
> Here is a preliminary version of the patch.

I don't understand the purpose of your patch. It just replaces a direct realloc() call with an indirect one (since _PyBytes_Resize() will call realloc() internally).
msg165884 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-19 22:06
> > Here is a preliminary version of the patch.
> 
> I don't understand the purpose of your patch. It just replaces a
> direct realloc() call with an indirect one (since _PyBytes_Resize()
> will call realloc() internally).

Ok, I understand. You're trying to make the getvalue() call cheaper,
right?
msg165901 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-20 06:42
> Ok, I understand. You're trying to make the getvalue() call cheaper,
> right?

Yes, it saves up to half of time on large data (on Linux). It would be 
interesting to see the results of these microbenchmarks on Windows.
msg165935 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-20 15:03
There seems to be a problem with the patch: when you store the getvalue() result somewhere (instead of discarding it), things get much slower:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
1000 loops, best of 3: 913 usec per loop

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"
100 loops, best of 3: 4.67 msec per loop

This does not happen without the patch.
msg165937 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-20 15:16
Under Windows (64-bit Windows 7 on a  VirtualBox VM), the patch increases performance slightly but not as much as under Linux:

-> before patch:

C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.g
etvalue()"
10 loops, best of 3: 49.2 msec per loop

-> after patch:

C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.g
etvalue()"
10 loops, best of 3: 41.7 msec per loop


And the join() approach is 10x faster (!):

C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
n,b'bb'*n,b'ccc'*n]*1000"  "b''.join(d)"
100 loops, best of 3: 4.63 msec per loop

... which points to a much less optimized realloc() under Windows.
msg165976 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-20 20:30
The patch updated. Fixed some errors, optimized initialization, added checks and comments. I think that now the patch is ready for review.
msg165977 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-20 20:32
> There seems to be a problem with the patch: when you store the getvalue() result somewhere (instead of discarding it), things get much slower:

This problem exists with the new patch?
msg165978 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-20 20:48
> Under Windows (64-bit Windows 7 on a  VirtualBox VM), the patch increases performance slightly but not as much as under Linux:

Thank you, Antoine. This is an expected result.

> And the join() approach is 10x faster (!):
> C:\t\cpython>pc\VS9.0\amd64\python.exe -m timeit -s "import io; n=2000; d=[b'a'*
> n,b'bb'*n,b'ccc'*n]*1000"  "b''.join(d)"
> 100 loops, best of 3: 4.63 msec per loop

To be fair, test body should be: "s=[]; w=s.append"  "for x in d: w(x)"  "b''.join(s)"

May be tuning resize strategy (overallocate not 1/8, but 1/4, 1/2, or 100%) can help.
msg165979 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-20 20:53
> > There seems to be a problem with the patch: when you store the
> getvalue() result somewhere (instead of discarding it), things get
> much slower:
> 
> This problem exists with the new patch?

I think you can run the benchmark yourself (I ran it under Linux).
msg165980 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-20 21:11
> I think you can run the benchmark yourself (I ran it under Linux).

I don't see any differences.
msg165981 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-20 21:18
Well, with the latest patch I get:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"
1000 loops, best of 3: 982 usec per loop

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"
100 loops, best of 3: 4.79 msec per loop
msg165995 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-21 06:30
Hmm. Without the ability to reproduce this effect, it will be difficult for me to 
get rid of him. What times for StringIO, append/join, unpatched BytesIO? Do 
this happen with a little different numbers (n=1500, 1600,...,3000)?
msg166005 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-21 10:15
> Hmm. Without the ability to reproduce this effect, it will be difficult for me to 
> get rid of him.

It's under 64-bit Linux, Intel Core i5 CPU. Are you sure you're testing
in non-debug mode?

That said, the numbers under Windows suggest me that Eli's original idea
(append and then join at the end) would be more robust.
msg166007 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-21 10:27
By the way, here is Matt Mackall's take on realloc():

http://www.selenic.com/pipermail/mercurial-devel/2011-October/034988.html
msg166008 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-21 10:37
StringIO:

$ ./python -m timeit -s "import io; n=2000; d=['a'*n,'bb'*n,'ccc'*n]*1000"  "s=io.StringIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"

-> Linux: 1000 loops, best of 3: 985 usec per loop
-> Windows: 100 loops, best of 3: 4.26 msec per loop

Unpatched BytesIO:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "global y; y = s.getvalue()"

-> Linux: 100 loops, best of 3: 2.44 msec per loop
-> Windows: 10 loops, best of 3: 38.4 msec per loop

b''.join():

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "l = list(d)"  "global y; y = b''.join(l)"

-> Linux: 1000 loops, best of 3: 821 usec per loop
-> Windows: 100 loops, best of 3: 4.09 msec per loop

bytearray:

$ ./python -m timeit -s "import io; n=2000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "b = bytearray()" "for x in d: b += x" "global y; y = b"

-> Linux: 1000 loops, best of 3: 834 usec per loop
-> Windows: 10 loops, best of 3: 37.8 msec per loop
msg166043 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-07-21 15:54
> It's under 64-bit Linux, Intel Core i5 CPU. Are you sure you're testing
> in non-debug mode?

I use 32-bit Linux.

> That said, the numbers under Windows suggest me that Eli's original idea
> (append and then join at the end) would be more robust.

I agree, it would be more robust, but much more complex solution. I will try to implement this approach too. Victor Stinner in their experiments with formatting preferred 
overallocation approach (_PyUnicodeWriter), therefore, the solution probably will be a hybrid.

However, even in itself the patch deserves attention. It not only significant speeds up writing under Linux, but also speeds up the initialization, which leads to faster reading.

./python -m timeit -s "import io; d=(b'a'*99+b'\n')*10000"  "s=io.BytesIO(d); r=s.readline"  "while r(): pass"

Unpatched:  100 loops, best of 3: 5.92 msec per loop
Patched:  100 loops, best of 3: 3.95 msec per loop

I will try to preserve this advantage.

> By the way, here is Matt Mackall's take on realloc():

Note, that list also uses realloc() inside and therefore you get the same behavior with other constant factor. Actually, appending to a list less than sizeof(void*) bytes at a 
time you will run into this sooner. Perhaps this is the cause that append/join approach under Windows slower than under Linux.

Thank you for measurements, this shows the scale of the issue.
msg171205 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-09-24 23:53
See also issue #15612 for a possible optimization on StringIO (use _PyUnicodeWriter).
msg202374 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-11-07 17:33
Updated patch uses large overallocation factor (1/2 instead 1/8), it may increase the speed on Windows. Fixed implementation of __sizeof__() and some minor bugs.
msg203034 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-11-16 12:10
Only one week left before feature freeze. Please benchmark this patch on Windows.
msg203045 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-16 14:41
> Only one week left before feature freeze.

This issue is an optimization, not a new feature.
msg224409 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-07-31 15:00
Synchronized with tip. Unfortunately there are no common points with recent issue22003 changes so they should be reverted (except tests).
msg225272 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-13 10:10
What should be made to move this issue forward?
msg225274 - (view) Author: David Wilson (dw) * Date: 2014-08-13 12:09
Hey Serhiy,

The implementation for your readline optimization seems less contentious (and less risky) than the remainder of the patch -- it could perhaps be easily split off into a separate patch, which may be far more easily committed.

I love the concept of this patch, although from my last reading (weeks ago), it's slightly scary that it relies on Py_REFCNT() to know whether to mutate a string or not. In principle this should never break, in practice, however, it is uncertain that there are no strange edge cases that aren't immediately obvious.

The _PyBytes_Resize doc is quite clear: "Only use this to build up a brand new bytes object; don’t use this if the bytes may already be known in other parts of the code"
msg225276 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-08-13 12:44
It wouldn't be the first time we've used Py_REFCNT that way. We do it with tuples and normal strings as well.
msg225295 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-14 10:29
Here is a patch which optimizes readline() and readlines() methods of BytesIO and the __next__() method of BytesIO iterator.
msg225298 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-08-14 13:44
I suppose this takes advantage of the libc's optimized memchr(). Any benchmarks?
(patch looks fine, by the way)
msg225306 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-14 17:26
Benchmark from issue22003:

$ ./python0 -m timeit -s 'import i' 'i.readlines()'

Before patch: 10 loops, best of 3: 36.1 msec per loop
After patch: 10 loops, best of 3: 27.5 msec per loop
msg225311 - (view) Author: Roundup Robot (python-dev) Date: 2014-08-14 19:34
New changeset 601045ceff94 by Serhiy Storchaka in branch 'default':
Issue #15381: Optimized line reading in io.BytesIO.
http://hg.python.org/cpython/rev/601045ceff94
msg225316 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-14 20:05
Updated patch without just committed line reading optimization and committed in issue22193 the _PySys_GetSizeOf() function.
msg225317 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-08-14 20:11
Can you post any benchmark?
Also, if you wouldn't change the resizing factor it would make it easier to compare the two approaches on their own merits, IMO.
msg225318 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-14 21:01
I posted benchmarks two years ago, in msg165795. Here are updated results:

$ ./python -m timeit -s "import io; n=100; d=[b'a'*n,b'bb'*n,b'ccc'*n]*10000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"

Before patch: 10 loops, best of 3: 42.3 msec per loop
After patch: 10 loops, best of 3: 27.6 msec per loop

$ ./python -m timeit -s "import io; n=1000; d=[b'a'*n,b'bb'*n,b'ccc'*n]*1000"  "s=io.BytesIO(); w=s.write"  "for x in d: w(x)"  "s.getvalue()"

Before patch: 10 loops, best of 3: 28.7 msec per loop
After patch: 100 loops, best of 3: 14.8 msec per loop

They don't depend from the resizing factor on Linux. I increased it in hope it will help on Windows.
msg234885 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-01-28 10:31
Ping.
msg235103 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-01-31 12:23
Updated patch addresses Antoine's comment.
msg235326 - (view) Author: Roundup Robot (python-dev) Date: 2015-02-03 09:31
New changeset 2e29d54843a4 by Serhiy Storchaka in branch 'default':
Issue #15381: Optimized io.BytesIO to make less allocations and copyings.
https://hg.python.org/cpython/rev/2e29d54843a4
msg235339 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-02-03 11:44
Some buildbots crash:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11152/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.x/builds/4/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/1715/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Solaris%2011%20%5BSB%5D%203.x/builds/3836/steps/test/logs/stdio

E.g.:

Fatal Python error: Objects/frameobject.c:429 object at 0x406dd878 has negative ref count -5

Current thread 0x40525ce0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 605 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 168 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1770 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1804 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1283 in test_runner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in <module>
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main
Aborted
make: *** [buildbottest] Error 134

Trying to reproduce locally and investigate.
msg235340 - (view) Author: Roundup Robot (python-dev) Date: 2015-02-03 12:58
New changeset 3fdbdf4d2ac7 by Serhiy Storchaka in branch 'default':
Issue #15381: Try to fix refcount bug. Empty and 1-byte buffers are always shared.
https://hg.python.org/cpython/rev/3fdbdf4d2ac7
msg235353 - (view) Author: Roundup Robot (python-dev) Date: 2015-02-03 16:53
New changeset ea33b61cac74 by Serhiy Storchaka in branch 'default':
Issue #15381: Fixed a bug in BytesIO.write().
https://hg.python.org/cpython/rev/ea33b61cac74
msg236003 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-02-14 22:47
Can this be closed now?
msg236007 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-02-14 23:05
No, I'm working on more advanced patch.
msg236011 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2015-02-14 23:44
Oh, Berker, please stop shaking up bug tracker.
History
Date User Action Args
2015-02-14 23:44:13BreamoreBoysetnosy: + BreamoreBoy
messages: + msg236011
2015-02-14 23:05:25serhiy.storchakasetmessages: + msg236007
2015-02-14 22:47:14berker.peksagsetnosy: + berker.peksag
messages: + msg236003
2015-02-03 16:53:52python-devsetmessages: + msg235353
2015-02-03 12:58:46python-devsetmessages: + msg235340
2015-02-03 11:44:44serhiy.storchakasetmessages: + msg235339
2015-02-03 09:31:05python-devsetmessages: + msg235326
2015-01-31 12:23:49serhiy.storchakasetfiles: + bytesio_resized_bytes-6.patch

messages: + msg235103
2015-01-28 10:31:11serhiy.storchakasetmessages: + msg234885
2014-10-14 18:00:34skrahsetnosy: - skrah
2014-08-14 21:01:52serhiy.storchakasetmessages: + msg225318
2014-08-14 20:11:43pitrousetmessages: + msg225317
2014-08-14 20:06:00serhiy.storchakasetfiles: + bytesio_resized_bytes-5.patch

messages: + msg225316
2014-08-14 19:34:52python-devsetmessages: + msg225311
2014-08-14 17:26:45serhiy.storchakasetmessages: + msg225306
2014-08-14 13:44:39pitrousetmessages: + msg225298
2014-08-14 10:29:22serhiy.storchakasetfiles: + bytesio_faster_readline.patch

messages: + msg225295
2014-08-13 12:44:32ncoghlansetmessages: + msg225276
2014-08-13 12:09:52dwsetmessages: + msg225274
2014-08-13 10:10:34serhiy.storchakasetmessages: + msg225272
2014-07-31 15:04:50serhiy.storchakasetnosy: + scoder, benjamin.peterson, stutzbach, skrah, python-dev, hynek, dw, kmike
2014-07-31 15:00:18serhiy.storchakasetfiles: + bytesio_resized_bytes-4.patch

messages: + msg224409
versions: + Python 3.5, - Python 3.4
2013-11-16 14:41:16vstinnersetmessages: + msg203045
2013-11-16 12:10:40serhiy.storchakasetmessages: + msg203034
2013-11-07 17:33:43serhiy.storchakasetfiles: + bytesio_resized_bytes-3.patch

messages: + msg202374
stage: needs patch -> patch review
2012-10-14 13:17:35eli.benderskysettitle: Optimize BytesIO to so less reallocations when written, similarly to StringIO -> Optimize BytesIO to do less reallocations when written, similarly to StringIO
2012-09-24 23:53:42vstinnersetmessages: + msg171205
2012-09-24 23:50:42vstinnersetnosy: + vstinner
2012-08-05 11:16:30serhiy.storchakasetassignee: serhiy.storchaka
2012-07-21 15:54:30serhiy.storchakasetmessages: + msg166043
2012-07-21 10:37:26pitrousetmessages: + msg166008
2012-07-21 10:27:20pitrousetmessages: + msg166007
2012-07-21 10:15:33pitrousetmessages: + msg166005
2012-07-21 06:30:21serhiy.storchakasetmessages: + msg165995
2012-07-20 21:18:45pitrousetmessages: + msg165981
2012-07-20 21:11:59serhiy.storchakasetmessages: + msg165980
2012-07-20 20:53:33pitrousetmessages: + msg165979
2012-07-20 20:48:26serhiy.storchakasetmessages: + msg165978
2012-07-20 20:32:04serhiy.storchakasetmessages: + msg165977
2012-07-20 20:30:58serhiy.storchakasetfiles: - bytesio_resized_bytes.patch
2012-07-20 20:30:28serhiy.storchakasetfiles: + bytesio_resized_bytes-2.patch

messages: + msg165976
2012-07-20 15:16:08pitrousetmessages: + msg165937
2012-07-20 15:03:28pitrousetmessages: + msg165935
2012-07-20 06:53:36eli.benderskysetassignee: eli.bendersky -> (no value)
2012-07-20 06:42:59serhiy.storchakasetmessages: + msg165901
2012-07-20 03:15:38meador.ingesetnosy: + meador.inge
2012-07-19 22:06:20pitrousetmessages: + msg165884
2012-07-19 22:04:36pitrousetmessages: + msg165883
2012-07-18 20:06:28serhiy.storchakasetfiles: + bytesio_resized_bytes.patch
keywords: + patch
messages: + msg165795
2012-07-18 14:29:55serhiy.storchakasetmessages: + msg165780
2012-07-18 11:58:40eli.benderskysetassignee: eli.bendersky
messages: + msg165760
2012-07-18 09:32:42eli.benderskysetmessages: + msg165748
2012-07-17 21:27:10Arfreversetnosy: + Arfrever
2012-07-17 13:44:31jconsetnosy: + jcon
2012-07-17 13:26:48serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg165718
2012-07-17 12:49:10eli.benderskysetmessages: + msg165716
2012-07-17 12:38:23tshepangsetnosy: + tshepang
2012-07-17 12:12:45eli.benderskycreate