Skip to content

bpo-30228: TextIOWrapper uses abs_pos, not tell()#1385

Closed
vstinner wants to merge 1 commit into
python:masterfrom
vstinner:textio_abs_pos
Closed

bpo-30228: TextIOWrapper uses abs_pos, not tell()#1385
vstinner wants to merge 1 commit into
python:masterfrom
vstinner:textio_abs_pos

Conversation

@vstinner

@vstinner vstinner commented May 2, 2017

Copy link
Copy Markdown
Member

The TextIOWrapper constructor now gets directly the abs_pos attribute
of BufferedWriter and BufferedRandom instead of calling the tell()
method to avoid one lseek() syscall on open(fname, "w") and
open(fname, "w+").

Move the buffered structure to _iomodule.h and rename it to
_PyIO_buffered. Add also "pythread.h" to _iomodule.h, needed by
_PyIO_buffered lock.

https://bugs.python.org/issue30228

@vstinner vstinner added the performance Performance or resource usage label May 2, 2017
@mention-bot

Copy link
Copy Markdown

@Haypo, thanks for your PR! By analyzing the history of the files in this pull request, we identified @benjaminp, @loewis and @serhiy-storchaka to be potential reviewers.

@vstinner

vstinner commented May 2, 2017

Copy link
Copy Markdown
Member Author

The TextIOWrapper constructor now gets directly the abs_pos attribute of BufferedWriter and BufferedRandom instead of calling the tell()

This change means that TextIOWrapper becomes inconsistent if the file descriptor is moved direcly using os.lseek()... but BufferedReader/BufferedWriter don't detect neither when the file descriptor is moved directly, no? I mean, abs_pos cached attribute already has the bug, no?

@vstinner

vstinner commented Jun 14, 2017

Copy link
Copy Markdown
Member Author

@pitrou: Would you mind to review this one? Does it look like an acceptable optimization?

@vstinner

Copy link
Copy Markdown
Member Author

@serhiy-storchaka: Same questions. Would you mind to review this one? Does it look like an acceptable optimization?

@pitrou

pitrou commented Jun 22, 2017

Copy link
Copy Markdown
Member

@Haypo: this looks like an acceptable optimization, but the question is whether it brings any significant speedup.

Comment thread Modules/_io/textio.c Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if it's not seekable?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we only go into this path if self->seekable is set.

Comment thread Modules/_io/textio.c Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about BufferedReader?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we only go into this path if self->encoder is set. self->encoder is only set if the buffer is writable.

@vstinner

vstinner commented Jul 6, 2017

Copy link
Copy Markdown
Member Author

@pitrou: I replied to your comments. So, what do you think? Is my PR safe?

@pitrou

pitrou commented Jul 6, 2017

Copy link
Copy Markdown
Member

As I said above : this looks like an acceptable optimization, but the question is whether it brings any significant speedup :-)

Of course I'm not against making optimizations in buffered I/O. I also know that buffering can be tricky (being responsible for the data corruption issue in Python 3.2 made me cautious about this!). But if this can increase performance significantly then ok (and you'll bear the responsability of any regression ;-)).

The TextIOWrapper constructor now gets directly the private abs_pos
attribute of BufferedWriter and BufferedRandom instead of calling the
tell() method to avoid one lseek() syscall on open(fname, "w") and
open(fname, "w+").

Move the buffered structure to _iomodule.h and rename it to
_PyIO_buffered. Add also "pythread.h" to _iomodule.h, needed by
_PyIO_buffered lock.
@vstinner

Copy link
Copy Markdown
Member Author

It's hard to see any significant speedup, so I abandon my change. The risk is not worth it.
https://bugs.python.org/issue30228#msg302307

@vstinner vstinner closed this Sep 16, 2017
@vstinner
vstinner deleted the textio_abs_pos branch September 16, 2017 01:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance Performance or resource usage skip news

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants