Alexei Alexandrov wrote: > I've also noticed that Vim spends somewhat significant time on startup > loading spell files (I have 2 languages in my .vimrc: set > spelllang=en,ru). The time is mostly spent in > EnterCriticalSection/LeaveCriticalSection with getc() upper the stack. > The reason for this is CRT blocking since the runtime is > multithreaded. It's Windows, but on Linux it should be similar.
I would not assume it's similar until there is proof. > As far as I understand, Vim doesn't access the spell file from > multiple threads. Thus, the situation can be improved a lot: on Linux > by using getc_unlocked. On Windows, starting VS 2005 there is a > function _getc_nolock. Before VS 2005 this function can be emulated by > macro: > > #define _getc_nolock(_stream) (--(_stream)->_cnt >= 0 ? \ > 0xff & *(_stream)->_ptr++ : _filbuf(_stream)) > > By switching to non-blocking getc() in spell.c I was able to reduce > Vim startup time from about 0.9 seconds to about 0.7 seconds. 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. 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. -- >From "know your smileys": :-E Has major dental problems /// 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 ///
