Message38049
Logged In: YES
user_id=31435
It would be better if get_line just called
Py_UniversalNewlineFgets (when appropriate) instead of
duplicating its logic inline.
Py_UniversalNewlineFgets and Py_UniversalNewlineFread
should deal with releasing the global lock themselves --
the correct granularity for lock release/reacquire is
around the C-level input routines (esp. for fread).
The new routines never check for I/O errors! Why not? It
seems essential.
The new Fgets checks for EOF at the end of the loop instead
of the top. This is surprising, and I stared a long time
in vain trying to guess why. Setting
newlinetypes |= NEWLINE_CR;
immediately after seeing an '\r' would be as fast (instead
of waiting to see EOF and then inferring the prior
existence of '\r' indirectly from the state of the
skipnextlf flag).
Speaking of which <wink>, the fobj tests in the inner loop
waste cycles. Set the local flag vrbls whether or not fobj
is NULL. When you're *out* of the inner loop you can
simply decline to store the new masks when fobj is NULL
(and you're already doing the latter anyway). A test and
branch inside the loop is much more expensive than or'ing
in a flag bit inside the loop, ditto harder to understand.
Floating the univ_newline test out of the loop (and
duplicating the loop body, one way for univ_newline true
and the other for it false) would also save a test and
branch on every character.
Doing fread one character at a time is very inefficient.
Since you know you need to obtain n characters in the end,
and that these transformations require reading at least n
characters, you could very profitably read n characters in
one gulp at the start, then switch to k at a time where k
is the number of \r\n pairs seen since the last fread
call. This is easier to code than it sounds <wink>.
It would be fine by me if you included (and initialized)
the new file-object fields all the time, whether or not
universal newlines are configured. I'd rather waste a few
bytes in a file object than see #ifdefs spread thru the
code.
I'll be damned if I can think of a quick way to do this
stuff on Windows -- native Windows fgets() is still the
only Windows handle we have on avoiding crushing thread
overhead inside MS's C library. I'll think some more about
it (the thrust still being to eliminate the 't' mode flag,
as whined about <wink> on Python-Dev). |
|
Date |
User |
Action |
Args |
2007-08-23 15:08:46 | admin | link | issue476814 messages |
2007-08-23 15:08:46 | admin | create | |
|