On Tue, Jul 17, 2012 at 2:59 PM, Serhiy Storchaka wrote:
> On 17.07.12 06:34, Eli Bendersky wrote:
>
>> The second approach is consistently 10-20% faster than the first one
>> (depending on input) for trunk Python 3.3
>>
>> Is there any reason for this to be so? What does BytesIO give us that
>> t
On 17.07.12 06:34, Eli Bendersky wrote:
The second approach is consistently 10-20% faster than the first one
(depending on input) for trunk Python 3.3
Is there any reason for this to be so? What does BytesIO give us that
the second approach does not (I tried adding more methods to the patched
Ra
On Tue, 17 Jul 2012 06:34:14 +0300
Eli Bendersky wrote:
>
> Is there any reason for this to be so? What does BytesIO give us that the
> second approach does not (I tried adding more methods to the patched
> RawIOBase to make it more functional, like seekable() and tell(), and it
> doesn't affect
On Tue, Jul 17, 2012 at 2:57 PM, John O'Connor wrote:
>>
>> The second approach is consistently 10-20% faster than the first one
>> (depending on input) for trunk Python 3.3
>>
>
> I think the difference is that StringIO spends extra time reallocating
> memory during the write loop as it grows, wh
>
> The second approach is consistently 10-20% faster than the first one
> (depending on input) for trunk Python 3.3
>
I think the difference is that StringIO spends extra time reallocating
memory during the write loop as it grows, whereas bytes.join computes
the allocation size first since it alr
While working on #1767933, Serhiy came up with an observation that
"monkey-patching" one of the base classes of io is faster than using
BytesIO when in need of a file-like object for writing into.
I've distilled it into this standalone test:
import io
data = [b'a'*10, b'bb'*5, b'ccc'*5] * 1
