[issue1407] [performance] Too many closed() checkings

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

[issue1407] [performance] Too many closed() checkings

Benjamin Peterson added the comment: Does io in C help with this? -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-l

[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.buff

[issue1407] [performance] Too many closed() checkings

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Is this issue still valid? -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___ ___

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

[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

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