[Tim]
> It's a shame that almost all vendors missed that fgets was defined
> as a primitive by the C committee precisely so that vendors *could*
> pull this speed trick under the covers. It's also a shame that Perl
> did it for them <wink>.
[Andrew Kuchling]
> So, should Python be changed to use fgets(), available on all ANSI C
> platforms, rather than the glibc-specific getline()? That would be
> more complicated than the brain-dead easy course of using getline(),
> which is obviously why I didn't do it; PyFile_GetLine() had annoyingly
> complicated logic.
The thrust of my original comment above is that fgets is almost never faster
than what Python is doing now, because vendors overwhelmingly do *not*
exploit the opportunity the std gave them. So, no, switching to fgets()
wouldn't help.
> When this was discussed in comp.lang.python, someone also mentioned
> getc_unlocked(), which saves the overhead of locking the stream every
> time, but that didn't seem a fruitful avenue for exploration.
Well, get_unlocked isn't std (not even in C99). Mentioning it did inspire
me to discover, however, that while the MS fgets() is the typical "getc in a
loop" thing, at least it locks/unlocks the stream once each at function
entry/exit, and uses a special MS flavor of getc ("_getc_lk") inside the
loop. However, that this helps is an illusion, because the body of their
_getc_lk macro is identical to the body of their getc macro. Smells like a
bug, or an unfinished project.
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