Skip to content

Conversation

@vstinner
Copy link
Member

@vstinner vstinner commented May 2, 2017

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

@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
Copy link
Member Author

vstinner commented May 2, 2017

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
Copy link
Member Author

vstinner commented Jun 14, 2017

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

@vstinner
Copy link
Member Author

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

@pitrou
Copy link
Member

pitrou commented Jun 22, 2017

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

Copy link
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
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.

Copy link
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
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
Copy link
Member Author

vstinner commented Jul 6, 2017

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

@pitrou
Copy link
Member

pitrou commented Jul 6, 2017

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
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