Possible bug: sluggy behaviour on slow FSes

[wa...@waba.be]

Hello,

I'm editing files located on a slow and laggy NFS share. I can deal with
the long opening and saving times, but I'm also encountering general
slugginess in vim, for example while inserting characters. Of course,
I've disabled the swap file feature (-n).

I've straced the problem: for every character typed, the following
syscalls take place (if I'm in /cwd, editing path/to/file):

open(".", O_RDONLY) = 5
fchdir(5) = 0
chdir("path/to") = 0
getcwd("/cwd/path/to"..., 4096) = 42
fchdir(5) = 0
close(5) = 0

This is perfectly fine on the local disk of a modern computer, but in my
case it is causing several hundred milliseconds of lag between each
character or command.

Firing up gdb (and a debug build), I've located the fchdir calls:

#0 0x00007ffd1733b600 in fchdir () from /lib/libc.so.6
#1 0x000000000051f1a9 in mch_FullName (fname=0xb3a920 "path/to/file", buf=0xb38a80 "", len=4096, force=<value optimized out>) at os_unix.c:2351
#2 0x0000000000583de9 in vim_FullName (fname=0xb3a920 "path/to/file", buf=0xb38a80 "", len=4096, force=0) at window.c:5992
#3 0x00000000004e32c3 in FullName_save (fname=0xb3a920 "path/to/file", force=0) at misc1.c:4702
#4 0x000000000049f232 in apply_autocmds_group (event=EVENT_CURSORMOVEDI, fname=0x0, fname_io=0x0, force=<value optimized out>, group=-3, buf=0xb351c0, eap=0x0) at fileio.c:8628
#5 0x000000000049f32a in apply_autocmds (event=EVENT_BUFFILEPOST, fname=0x0, fname_io=0x2 <Address 0x2 out of bounds>, force=0, buf=<value optimized out>) at fileio.c:8404
#6 0x00000000004487ee in ins_redraw (ready=1) at edit.c:1469
#7 0x0000000000450764 in edit (cmdchar=111, startln=<value optimized out>, count=1) at edit.c:688
#8 0x00000000004fd273 in invoke_edit (cap=0x7fff22ad9790, repl=<value optimized out>, cmd=111, startln=1) at normal.c:8846
#9 0x00000000004feff0 in nv_open (cap=0x7fff22ad9790) at normal.c:8160
#10 0x0000000000504293 in normal_cmd (oap=0x7fff22ad9830, toplevel=1) at normal.c:1181
#11 0x00000000004c470b in main_loop (cmdwin=0, noexmode=0) at main.c:1182
#12 0x00000000004c7697 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:941

and (the rest is identical)

#1 0x000000000051f045 in mch_FullName (fname=0xb3a930 "file", buf=0xb38a80 "/cwd/path/to", len=4096, force=<value optimized out>) at os_unix.c:2417

This doesn't happen with -u NONE or if I move away my .vimrc, but does
happen if I create an empty (0 bytes) .vimrc. The global config file
exists but its contents are commented out. Therefore, I don't think that
this could be the result of a badly designed script.

Even more interesting, starting vim with -u NONE and then sourcing my
usual .vimrc gives me back the power and speed of my favourite text
editor...

At least, this workaround allows me to work without copying files back
and forth. Is there something obvious that I missed, or did I bump into
a bug?

Thanks in advance,
-Thomas Equeter.

PS: the generated bugreport.txt is at http://waba.be/tmp/bugreport.txt

[Matt Wozniski]

On Sat, Aug 23, 2008 at 9:22 AM, Thomas Equeter wrote:
> Hello,
>
> I'm editing files located on a slow and laggy NFS share. I can deal with
> the long opening and saving times, but I'm also encountering general
> slugginess in vim, for example while inserting characters. Of course,
> I've disabled the swap file feature (-n).
>
> I've straced the problem: for every character typed, the following
> syscalls take place (if I'm in /cwd, editing path/to/file):
>
> open(".", O_RDONLY) = 5
> fchdir(5) = 0
> chdir("path/to") = 0
> getcwd("/cwd/path/to"..., 4096) = 42
> fchdir(5) = 0
> close(5) = 0

<SNIP>

> This doesn't happen with -u NONE or if I move away my .vimrc, but does
> happen if I create an empty (0 bytes) .vimrc. The global config file
> exists but its contents are commented out. Therefore, I don't think that
> this could be the result of a badly designed script.
>
> Even more interesting, starting vim with -u NONE and then sourcing my
> usual .vimrc gives me back the power and speed of my favourite text
> editor...
>
> At least, this workaround allows me to work without copying files back
> and forth. Is there something obvious that I missed, or did I bump into
> a bug?
>
> Thanks in advance,
> -Thomas Equeter.

-u NONE disables the user .vimrc, system .vimrc, and plugins. Try
launching with --noplugin to only disable plugins and see if that
helps. One possibility is that this behavior is caused by a plugin
doing something crazy on cursormoved and cursormovedi.

~Matt

[John Beckett]

waba wrote:
> This doesn't happen with -u NONE or if I move away my .vimrc,
> but does happen if I create an empty (0 bytes) .vimrc.

Matt's post sounds like it's going to work. It makes me think you could also try
this:

:verbose au CursorMoved
:verbose au CursorMovedI

These are set by matchparen.vim on my system.

John

[Tony Mechelynck]

If you start without a vimrc, it usually means 'compatible' mode. Not so
if a vimrc (even an empty one) is found. Now setting 'nocompatible' has
the effect of changing a lot of other options, see ":help 'compatible'".
Maybe one (or more) of these is respoonsible for the behaviour you notice.

Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
142. You dream about creating the world's greatest web site.

[waba]

Thanks a lot for your answers.

I've just checked, the only CursorMoved[I] autocommands configured
here
are those of the standard matchparen.vim. Disabling them
(:NoMatchParen)
"fixes" the problem, but actually the cause is not in the script
itself.

Indeed, I can reproduce the issue in a "-u NONE" vim instance by
defining an empty function and registering it as a CursorMoved[I]
autocommand:

:function Noop()
:endfunction
:au CursorMoved * call Noop()
:au CursorMovedI * call Noop()

Is there anything that I missed? Should I report this on the vim-dev
ML?

TIA,
-Thomas.

[John Beckett]

waba wrote:
> Indeed, I can reproduce the issue in a "-u NONE" vim instance
> by defining an empty function and registering it as a CursorMoved[I]
> autocommand:
>
> :function Noop()
> :endfunction
> :au CursorMoved * call Noop()
> :au CursorMovedI * call Noop()
>
> Is there anything that I missed? Should I report this on the
> vim-dev ML?

Interesting. Please write up a simple case, mentioning the operating system and
version of Vim, the exact command to start it, and a trace of the stuff you
mentioned earlier. It would be good if you posted it in vim_dev.

John

[Bram Moolenaar]

Thomas Waba wrote:

I guess this is because mch_FullName() is invoked. That might be hard
to avoid.

--
Contrary to popular belief, it's often your clothing that gets promoted, not
you.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///

[wa...@waba.be]

On Mon, Aug 25, 2008 at 05:27:31AM +0200, Bram Moolenaar wrote:
> I guess this is because mch_FullName() is invoked.

It is, according to the backtrace.

> That might be hard to avoid.

Do you mean that my only option is disabling parenthesis matching (and
other commonly triggered autocommands) when editing such files?

-Thomas.

[Bram Moolenaar]

Thomas Equeter wrote:

I haven't looked into why exactly mch_FullName() is invoked.
It is often needed when file names are compared, to make sure relative
paths and things like that are expanded properly.

--
hundred-and-one symptoms of being an internet addict:

2. You kiss your girlfriend's home page.

[Thomas Equeter]

On Tue, Aug 26, 2008 at 05:11:17AM +0200, Bram Moolenaar wrote:
> I haven't looked into why exactly mch_FullName() is invoked.
> It is often needed when file names are compared, to make sure relative
> paths and things like that are expanded properly.

In this case it seems to be invoked for all buffers that have a filename
associated somehow, in order to compute <aname> (according to the
comment line 8612 of fileio.c.)

However, I've just noticed that it promptly returns when given an
absolute path. Therefore, "$PWD/" is probably the easiest and most
efficient workaround for this issue.

This said, it may be desirable to fix the root cause somehow (by caching
<afile> or the mch_FullName() result?), but that's outside the scope of
what I can investigate right now.

Regards,
-Thomas.