mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-09-26 18:29:57 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10

rewrite

Browse source
This commit is contained in:
Benjamin Peterson 2011-02-24 02:53:05 +00:00
parent 634ef9cb81
commit 5390d00cc6
1 changed files with 24 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

49
Doc/library/io.rst
View file

@ -788,31 +788,30 @@ Text I/O
Performance Performance
----------- -----------
This section discusses the performance of the provided concrete IO This section discusses the performance of the provided concrete I/O
implementations. implementations.
Binary I/O Binary I/O
^^^^^^^^^^ ^^^^^^^^^^
By reading and writing only large chunks of data even when the user asks By reading and writing only large chunks of data even when the user asks for a
for a single byte, buffered I/O is designed to hide any inefficiency in single byte, buffered I/O hides any inefficiency in calling and executing the
calling and executing the operating system's unbuffered I/O routines. The operating system's unbuffered I/O routines. The gain depends on the OS and the
gain will vary very much depending on the OS and the kind of I/O which is kind of I/O which is performed. For example, on some modern OSes such as Linux,
performed (for example, on some contemporary OSes such as Linux, unbuffered unbuffered disk I/O can be as fast as buffered I/O. The bottom line, however,
disk I/O can be as fast as buffered I/O). The bottom line, however, is is that buffered I/O offers predictable performance regardless of the platform
that buffered I/O will offer you predictable performance regardless of the and the backing device. Therefore, it is most always preferable to use buffered
platform and the backing device. Therefore, it is most always preferable to I/O rather than unbuffered I/O for binary datal
use buffered I/O rather than unbuffered I/O.
Text I/O Text I/O
^^^^^^^^ ^^^^^^^^
Text I/O over a binary storage (such as a file) is significantly slower than Text I/O over a binary storage (such as a file) is significantly slower than
binary I/O over the same storage, because it implies conversions from binary I/O over the same storage, because it requires conversions between
unicode to binary data using a character codec. This can become noticeable unicode and binary data using a character codec. This can become noticeable
if you handle huge amounts of text data (for example very large log files). handling huge amounts of text data like large log files. Also,
Also, :meth:`TextIOWrapper.tell` and :meth:`TextIOWrapper.seek` are both :meth:`TextIOWrapper.tell` and :meth:`TextIOWrapper.seek` are both quite slow
quite slow due to the reconstruction algorithm used. due to the reconstruction algorithm used.
:class:`StringIO`, however, is a native in-memory unicode container and will :class:`StringIO`, however, is a native in-memory unicode container and will
exhibit similar speed to :class:`BytesIO`. exhibit similar speed to :class:`BytesIO`.
@ -820,9 +819,8 @@ exhibit similar speed to :class:`BytesIO`.
Multi-threading Multi-threading
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^
:class:`FileIO` objects are thread-safe to the extent that the operating :class:`FileIO` objects are thread-safe to the extent that the operating system
system calls (such as ``read(2)`` under Unix) they are wrapping are thread-safe calls (such as ``read(2)`` under Unix) they wrap are thread-safe too.
too.
Binary buffered objects (instances of :class:`BufferedReader`, Binary buffered objects (instances of :class:`BufferedReader`,
:class:`BufferedWriter`, :class:`BufferedRandom` and :class:`BufferedRWPair`) :class:`BufferedWriter`, :class:`BufferedRandom` and :class:`BufferedRWPair`)
@ -837,12 +835,13 @@ Reentrancy
Binary buffered objects (instances of :class:`BufferedReader`, Binary buffered objects (instances of :class:`BufferedReader`,
:class:`BufferedWriter`, :class:`BufferedRandom` and :class:`BufferedRWPair`) :class:`BufferedWriter`, :class:`BufferedRandom` and :class:`BufferedRWPair`)
are not reentrant. While reentrant calls will not happen in normal situations, are not reentrant. While reentrant calls will not happen in normal situations,
they can arise if you are doing I/O in a :mod:`signal` handler. If it is they can arise from doing I/O in a :mod:`signal` handler. If a thread tries to
attempted to enter a buffered object again while already being accessed renter a buffered object which it is already accessing, a :exc:`RuntimeError` is
*from the same thread*, then a :exc:`RuntimeError` is raised. raised. Note this doesn't prohibit a different thread from entering the
buffered object.
The above implicitly extends to text files, since the :func:`open()` The above implicitly extends to text files, since the :func:`open()` function
function will wrap a buffered object inside a :class:`TextIOWrapper`. This will wrap a buffered object inside a :class:`TextIOWrapper`. This includes
includes standard streams and therefore affects the built-in function standard streams and therefore affects the built-in function :func:`print()` as
:func:`print()` as well. well.