Alexei Alexandrov wrote:
> > This sounds like a bug in getc(). It should know that only one thread
> > is reading the file and skip the locking. I don't think we should fix
> > library bugs in Vim, unless it's crashing or another significant problem.
> >
> It can't be a bug. I might be missing what you mean, but I can't see
> how it can know that only one thread is reading a file. It doesn't
> have a clue whether you gave this FILE * to other threads or not. It
> tries to be lightweight - as I described in a separate mail it uses
> InterlockedIncrement/Decrement but they are not that lightweight -
> they don't require switching to kernel mode but still take about 200
> cycles of CPU each.
>
> The only optimization that I see could be avoiding blocking (and even
> trying to block) in case if there is only one thread in current
> process and if there is guarantee that this particular call is
> guaranteed not to create any threads. But 1) it still may be expensive
> and 2) Vim has some background threads anyway, probably.
Hmm, getc() is apparently preparing for the worst and isn't optimized
for the 98% of the situations where there is only one thread reading
from the fd. With the result that the, very often used, getc() is slow.
Besides using getc_unlocked() we could use read() and do our own
buffering. That can't bee very complicated. And we don't need to
figure out if the getc_unlocked() function is available.
--
hundred-and-one symptoms of being an internet addict:
102. When filling out your driver's license application, you give
your IP address.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
