[issue1407] [performance] Too many closed() checkings
Benjamin Peterson benja...@python.org added the comment: Does io in C help with this? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1407] [performance] Too many closed() checkings
Antoine Pitrou pit...@free.fr added the comment: Closing, as I don't think there's any point trying to micro-optimize the Python version. -- resolution: later - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1407] [performance] Too many closed() checkings
Antoine Pitrou [EMAIL PROTECTED] added the comment: Is this issue still valid? -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1407] [performance] Too many closed() checkings
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: 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. -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1407] [performance] Too many closed() checkings
Guido van Rossum added the comment: 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 abc.py being called, which surprised me slightly. I haven't had time to look into this further though. -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1407 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1407] [performance] Too many closed() checkings
Christian Heimes added the comment: The problem should be addressed after the last alpha during the optimization and cleanup phase. -- components: +Interpreter Core, Library (Lib) -Build keywords: +py3k nosy: +tiran priority: - normal resolution: - later __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1407 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1407] [performance] Too many closed() checkings
New submission from Wojciech Walczak:
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='')
builtin_function_or_method.print
method.write
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
function.closed
!method.write # here it goes again for 'end' parameter
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
builtin_function_or_method.displayhook
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?
Regards,
Wojtek Walczak
--
components: Build
messages: 57275
nosy: wojtekwalczak
severity: minor
status: open
title: [performance] Too many closed() checkings
type: resource usage
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1407
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
