[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] vim slow



On 30/09/14 00:23, Vincent Rivière wrote:
> Hello.
>
> I have noticed that vim was slow in input mode. Just type a character,
> and it takes a fraction of second to be displayed. Even worse, if you
> keep the key pressed for key repeat, the characters are only displayed
> when you release the keys. Because the processing of each character is
> too slow. This slowdown only occurs in input mode, on the opposite
> command mode "Esc :" is very fast.
>
> This slowdown occurs identically on the FireBee and ARAnyM. It is very
> surprising because they are 2 fast machines. And ARAnyM has an
> extremely fast CPU, I can't believe that something could be slow on
> it. So I thought at some kernel issue.
>
> By looking at the vim sources and running it with strace, it seems
> that vim examines multiple times the terminal to see if characters are
> available. With the current MiNTLib, it falls into Fpoll(). I see the
> source in the kernel: sys/dosfile.c, function sys_f_poll().
>
> I don't fully understand that function, but it looks strange.
> Around line 1264, there is:
>     if (count == 0)
>     {
>         /* no data is ready yet */
>
> Then there is wait stuff like addtimeout(), spl7(), etc.
> That wait code is called even when the timeout value is 0, I can't
> understand why. I would expect it would just return immediately.
> As an experiment, if I put a "goto cancel;" at that place, vim
> suddenly becomes very fast, as expected.
>
> So I wonder if the current code of sys_f_poll() is correct or not.
> If there is a bug there, the fix could speed up many things.
>
> Any thoughts?
>

The timeout gets modified in the call as 0 means unlimited, so it's set
to 1 for the smallest amount of wait time. I guess it could be modified
so it doesn't even call the timeout in that case. If so, is that
sufficient to improve the speed ?

Alan.