> > > Dunno why the unbuffered reading would be slow. I'd think it would still > > > read large chunks at a time when you request it. > > > > System call overhead? I had the same complaint about Windows, where > > apparently winsock makes you pay more of a performance penalty than > > Unix does in the same case. > > Shouldn't be. There should still be an rfile.read(1000) in that example app > (with the big transfers). That read() should be quite fast -- the buffering > should have almost no effect. > > So... what is the underlying problem? > > [ IOW, there are two issues: the sock vs file thing; and why rfile is so > darn slow; I have no insights on the latter. ] Should, shouldn't... It's a quality of implementation issue in stdio. If stdio, when seeing a large read on an unbuffered file, doesn't do something smart but instead calls getc() for each character, that would explain this. It's dumb, but not illegal. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4