Kristján Valur Jónsson <[EMAIL PROTECTED]> added the comment: If you look at http://bugs.python.org/issue4336, half of the proposed patch is an attempt to deal with this performance issue. In the patch, we laboriously ensure that bufsize=-1 is passed in for for the xmlrpc client.
Seeing your comment, I realize that xmlrpclib.py also uses direct access to h._conn.sock (if present) and uses recv() on that. In fact, that is the only place in the standard library where I can find this pattern. Was that a performance improvement? It is hard to see how bypassing buffered read with a manual recv() can significantly alter performance. In all the cases in the test_xmlrpc.py, h._conn.sock is actually None because h._conn has been closed in HttpConnection.getresponse() Therefore, my patch continues to work. However, I will fix that patch to cater to this strange special case. However, please observe that since _fileobject.read() calls are always buffered, in general there is no way to safely mix read() and recv() calls, althought the recv() and readline() has been fudged to work. Isn´t this just a case of a wart in the standard lib that we ought to remove? Here is a suggestion: 1) document why readline() observes 0 buffering (to enable it to be used as a readline() utility tool on top of vanilla socket recv() 2) stop doing that in xmrlrpclib and use default buffering. ---------- nosy: +krisvale _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4448> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com