Hi Bram Moolenaar, you wrote: >> It's Windows, but on Linux it should be similar. > > I would not assume it's similar until there is proof. > Of course. I'm going to investigate it there.
> > 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. > Perhaps you can already get a big increase by not compiling for > debugging? With MSVC this usually has a big impact. Also largely > defeats profiling with debugging enabled. > I do _all_ performance measurements using optimized version of binary with symbols. This is just a must for performance tuning. -- Alexei Alexandrov
