[issue13149] optimization for append-only StringIO

Antoine Pitrou added the comment: I've committed an improved version (which also optimizes seek(0); read()). -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___

[issue13149] optimization for append-only StringIO

Roundup Robot added the comment: New changeset 8d9a869db675 by Antoine Pitrou in branch 'default': Issue #13149: Speed up append-only StringIO objects. http://hg.python.org/cpython/rev/8d9a869db675 -- nosy: +python-dev ___ Python tracker

[issue13149] optimization for append-only StringIO

Terry J. Reedy added the comment: Like parts of the Python test suite, I use StringIO to capture print/write output for testing in an output...output/getvalue/reset(seek(0),truncate(0)) cycle. While this enhancement would not currently affect me (as I only do a few prints each cycle), I can e

[issue13149] optimization for append-only StringIO

Antoine Pitrou added the comment: Yes, these are things I've been wondering about. The use-case for an append-only StringIO is obviously overlapping with the use-case for using ''.join(). However, the implementation I'm proposing is better than ''.join() when writing very small strings, since

[issue13149] optimization for append-only StringIO

Martin v. Löwis added the comment: It would be interesting to see how often the "bad" case triggers, i.e. that a write-only stringio sees any of the other methods invoked at all. As a special case, you may consider that .truncate(0) doesn't really need to realize the buffer first. I also wond

[issue13149] optimization for append-only StringIO

New submission from Antoine Pitrou : io.StringIO is quite slower than ''.append() when used for mass concatenation (around 5x slower). This patch brings it to similar performance by deferring construction of the internal buffer until needed. The problem is that it's very easy to disable the op