This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: [performance] Too many closed() checkings
Type: resource usage Stage:
Components: Interpreter Core, Library (Lib) Versions: Python 3.0
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, benjamin.peterson, christian.heimes, gvanrossum, pitrou, wojtekwalczak
Priority: normal Keywords:

Created on 2007-11-08 20:30 by wojtekwalczak, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg57275 - (view) Author: Wojciech Walczak (wojtekwalczak) * Date: 2007-11-08 20:30
For debugging reasons I have added a simple line to PyObject_Call()
function in Objects/abstract.c:
printf("%s.%s\n", func->ob_type->tp_name, PyEval_GetFuncName(func));
Now, after compiling python and running interpreter with simple
print() call I receive this:

Python 3.0a1 (py3k, Nov  6 2007, 19:25:33)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('!',end='')
!method.write   # here it goes again for 'end' parameter

Note that there can be something going on between one function.closed 
and the next one, because not every piece of code gets called by 
PyObject_Call(), but still - isn't it checking if stream is closed a 
bit too often?

Wojtek Walczak
msg57276 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-11-08 20:56
The problem should be addressed after the last alpha during the
optimization and cleanup phase.
msg57320 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-11-09 19:32
To find out what really happens, use pdb to step through the example.
This gives much better insight than adding a printf() call to
PyObject_Call(). I've notice myself when stepping through I/O that there
are a lot of checks for closed -- this may have to do with the stacking
text -> buffer -> binary though. I've also noticed overridden isinstance
checks in being called, which surprised me slightly. I haven't
had time to look into this further though.
msg68151 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-06-13 12:47
Is this issue still valid?
msg68157 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-06-13 13:37
I reproduce almost the same output.
"function.closed" often come in pair, because TextIOWrapper.closed is a
property which delegates to self.buffer.closed

I think that the first check in TextIOWrapper.write() is not necessary:
self.buffer.write(b) will also check for "self.buffer.closed", and there
is not much code in-between. The only side-effect is the decoder state.
msg82926 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-02-28 17:21
Does io in C help with this?
msg82932 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-02-28 18:11
Closing, as I don't think there's any point trying to micro-optimize the
Python version.
Date User Action Args
2022-04-11 14:56:28adminsetgithub: 45748
2009-02-28 18:11:10pitrousetstatus: open -> closed
resolution: later -> wont fix
messages: + msg82932
2009-02-28 17:21:59benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg82926
2008-06-13 13:37:13amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg68157
2008-06-13 12:47:27pitrousetnosy: + pitrou
messages: + msg68151
2008-01-06 22:29:45adminsetkeywords: - py3k
versions: Python 3.0
2007-11-09 19:32:53gvanrossumsetnosy: + gvanrossum
messages: + msg57320
2007-11-08 20:56:18christian.heimessetnosy: + christian.heimes
messages: + msg57276
priority: normal
components: + Interpreter Core, Library (Lib), - Build
keywords: + py3k
resolution: later
2007-11-08 20:30:33wojtekwalczakcreate