RedHat Athena: GUI vim is extremely slow using terminal

[Aleksandr Jakušev]

Hi,

We have Red Hat Enterprise Linux Server release 7.8 (Maipo), which by default has vim 7.4 installed. I am trying to compile the latest vim 8.2 (official release, without later patches). I went the usual way: download the sources, configure (default settings, only --prefix redefined), make, make install ... And got the following build:

======================================================================

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May  7 2021 15:42:09)

Compiled by xxxxxxxxxxx

Huge version with X11-Athena GUI.  Features included (+) or not (-):

+acl               -farsi             -mouse_sysmouse    -tag_old_static

+arabic            +file_in_path      +mouse_urxvt       -tag_any_white

+autocmd           +find_in_path      +mouse_xterm       -tcl

+autochdir         +float             +multi_byte        +termguicolors

-autoservername    +folding           +multi_lang        +terminal

+balloon_eval      -footer            -mzscheme          +terminfo

+balloon_eval_term +fork()            +netbeans_intg     +termresponse

+browse            +gettext           +num64             +textobjects

++builtin_terms    -hangul_input      +packages          +textprop

+byte_offset       +iconv             +path_extra        +timers

+channel           +insert_expand     -perl              +title

+cindent           +job               +persistent_undo   +toolbar

+clientserver      +jumplist          +popupwin          +user_commands

+clipboard         +keymap            +postscript        +vartabs

+cmdline_compl     +lambda            +printer           +vertsplit

+cmdline_hist      +langmap           +profile           +virtualedit

+cmdline_info      +libcall           -python            +visual

+comments          +linebreak         -python3           +visualextra

+conceal           +lispindent        +quickfix          +viminfo

+cryptv            +listcmds          +reltime           +vreplace

+cscope            +localmap          +rightleft         +wildignore

+cursorbind        -lua               -ruby              +wildmenu

+cursorshape       +menu              +scrollbind        +windows

+dialog_con_gui    +mksession         +signs             +writebackup

+diff              +modify_fname      +smartindent       +X11

+digraphs          +mouse             -sound             +xfontset

-dnd               +mouseshape        +spell             +xim

-ebcdic            +mouse_dec         +startuptime       +xpm

+emacs_tags        -mouse_gpm         +statusline        +xsmp_interact

+eval              -mouse_jsbterm     -sun_workshop      +xterm_clipboard

+ex_extra          +mouse_netterm     +syntax            -xterm_save

+extra_search      +mouse_sgr         +tag_binary        

   system vimrc file: "$VIM/vimrc"

     user vimrc file: "$HOME/.vimrc"

 2nd user vimrc file: "~/.vim/vimrc"

      user exrc file: "$HOME/.exrc"

  system gvimrc file: "$VIM/gvimrc"

    user gvimrc file: "$HOME/.gvimrc"

2nd user gvimrc file: "~/.vim/gvimrc"

       defaults file: "$VIMRUNTIME/defaults.vim"

    system menu file: "$VIMRUNTIME/menu.vim"

  fall-back for $VIM: "xxxxxxx/vim"

Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -DFUNCPROTO=15 -DNARROWPROTO    -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       

Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim -lXaw -lXmu -lXext -lXt -lSM -lICE -lXpm -lXt -lX11 -lSM -lICE -ldl  -lm -ltinfo -lnsl  -lselinux -ldl           

======================================================================

The problem with this build is that the GUI version is very slow. For example, it takes about 6 sec to start. Below are some unnecessary large timings from the startup profiling:

==================================================

161.380  159.404: expanding arguments

...

1344.137  1143.949  1143.949: sourcing .../share/vim/vim82/ftplugin/man.vim

...

5302.964  3903.539: starting GUI

==================================================

Once started, gvim more or less works, until I decide to use the terminal functionality. This is where the things become really indecent. Forget using the terminal interactively, a simple ":term ls -l" takes several minutes to run. Gvim is unresponsive during this time. Once the terminal window becomes finished, gvim becomes responsive again, but will periodically hang if you decide to navigate in the finished terminal window. During gvim hanging, the call stack looks like this:

==================================================

PID 2468 - process

TID 2468:

#0  0x00007f3469b62c20     poll - /usr/lib64/libc-2.17.so

#1  0x00007f346943c022 - 1 _xcb_conn_wait - /usr/lib64/libxcb.so.1.1.0

#2  0x00007f346943d99f - 1 wait_for_reply - /usr/lib64/libxcb.so.1.1.0

#3  0x00007f346943db12 - 1 xcb_wait_for_reply64 - /usr/lib64/libxcb.so.1.1.0

#4  0x00007f346a7d70f0 - 1 _XReply - /usr/lib64/libX11.so.6.3.0

#5  0x00007f346a7bbd3f - 1 XAllocColor - /usr/lib64/libX11.so.6.3.0

#6  0x00000000005d238a - 1 - .../usr/local/bin/vim

#7  0x000000000059537a - 1 - .../usr/local/bin/vim

#8  0x0000000000595d1c - 1 - .../usr/local/bin/vim

#9  0x000000000059c73e - 1 - .../usr/local/bin/vim

#10 0x000000000043db48 - 1 - .../usr/local/bin/vim

#11 0x000000000043fba5 - 1 - .../usr/local/bin/vim

#12 0x00000000005fbf5c - 1 - .../usr/local/bin/vim

#13 0x00000000005fd17a - 1 - .../usr/local/bin/vim

#14 0x000000000040bcb2 - 1 - .../usr/local/bin/vim

#15 0x00007f3469a91555 - 1 __libc_start_main - /usr/lib64/libc-2.17.so

#16 0x000000000040d6f4 - 1 - .../usr/local/bin/vim

==================================================

Which makes me thing that the problem is GUI/X server related. And true, this does not happen in the console verion of vim.  FYI, My X server is one of the latest versions of vcxsrv running on Win 10.

I believe that the version of vim 7.4 that comes preinstalled is faster. Unfortunately, vim 7.4 does not have the terminal functionality to compare the same things, but its start-up times are much faster, without the lags above (same vimrc is used). The vim 7.4 is built with -DFEAT_GUI_GTK and various gtk header folders included. I don't have those headers on my server, that's why GTK GUI is not used by configure...

Any advice would be appreciated.

[Dominique Pellé]

Aleksandr Jakušev wrote:

> I am trying to compile the latest vim 8.2 (official release,
> without later patches)

I don't know whether it will fix your problem, but I would
advise to use the latest from git which at the time I write
this is vim-8.2.2842. By using vim-8.2.0000 (Dec 12, 2019),
you're missing a lot of bug fixes.

> The vim 7.4 is built with -DFEAT_GUI_GTK and various
> gtk header folders included. I don't have those headers
> on my server, that's why GTK GUI is not used by configure

What about trying with the motif GUI?

Regards
Dominique

[Dominique Pellé]

Aleksandr Jakušev wrote:


> We have Red Hat Enterprise Linux Server release 7.8 (Maipo), which by default has
> vim 7.4 installed

> ...snip...

>
FYI, My X server is one of the latest versions of vcxsrv running on Win 10.

Ah, your X server is not running on the same machine (Win 10)
as where gvim runs (Linux). Running X applications remotely
is very slow (that's not specific to Vim).

Much faster would be to use vnc or rdesktop, so the
X server would be on the same Linux machine as GVim.

Dominique

[Aleksandr Jakušev]

Hi,

I have tried building with the motif GUI, but it does not generate the GUI version of vim. I guess some headers are missing on my system. Unfortunately, I am not the admin on that machine, so my options on what to install are limited.

Also, I had motif gvim 8.1 on some older machine, the terminal support was equally slow.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/m6hjxFc7xmI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_hUDBKnbQhtV1E5ZyRS8MtxxzzyW7rM%2B6hodWfLUseqTQ%40mail.gmail.com.

--

Best regards,

Alex J.

[Aleksandr Jakušev]

Hm ... I do not agree.

Obviously, running x server remotely makes everything much slower, but

1. Not that slower! I am not expecting gvim to run at 120FPS, but several minutes for "term ls -l" is too much even for remote X server

2. Editing normal files, even with syntax highlighting, is not (that) slow. I would expect similar speeds running simple commands in :term

 

In other words, I still believe that there is some quirk in vim terminal implementation that makes it work extremely slow in X11 GUI vim (in my case ).

Alex

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/m6hjxFc7xmI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_j4VQb99RoLXMpV0%2Bb8Af6U2j81fWT58Y_JrsSbqmr9uA%40mail.gmail.com.

[Bram Moolenaar]

Aleksandr Jakušev wrote:

> We have Red Hat Enterprise Linux Server release 7.8 (Maipo), which by
> default has vim 7.4 installed. I am trying to compile the latest vim 8.2
> (official release, without later patches). I went the usual way: download
> the sources, configure (default settings, only --prefix redefined), make,
> make install ... And got the following build:
>
> ======================================================================
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 7 2021 15:42:09)
> Compiled by xxxxxxxxxxx
> Huge version with X11-Athena GUI. Features included (+) or not (-):

[...]

> ======================================================================
>
> The problem with this build is that the GUI version is very slow. For
> example, it takes about 6 sec to start. Below are some unnecessary large
> timings from the startup profiling:
>
> ==================================================
> 161.380 159.404: expanding arguments
> ...
> 1344.137 1143.949 1143.949: sourcing .../share/vim/vim82/ftplugin/man.vim
> ...

> 5302.964 *3903.539*: starting GUI

> ==================================================
>
> Once started, gvim more or less works, until I decide to use the terminal
> functionality. This is where the things become really indecent. Forget
> using the terminal interactively, a simple ":term ls -l" takes several
> minutes to run. Gvim is unresponsive during this time. Once the terminal
> window becomes finished, gvim becomes responsive again, but will
> periodically hang if you decide to navigate in the finished terminal
> window. During gvim hanging, the call stack looks like this:
>
> ==================================================
> PID 2468 - process
> TID 2468:
> #0 0x00007f3469b62c20 poll - /usr/lib64/libc-2.17.so

[...]

> #16 0x000000000040d6f4 - 1 - .../usr/local/bin/vim
> ==================================================
>
> Which makes me thing that the problem is GUI/X server related. And true,
> this does not happen in the console verion of vim. FYI, My X server is one
> of the latest versions of vcxsrv running on Win 10.
>
> I believe that the version of vim 7.4 that comes preinstalled is faster.
> Unfortunately, vim 7.4 does not have the terminal functionality to compare
> the same things, but its start-up times are much faster, without the lags
> above (same vimrc is used). The vim 7.4 is built with -DFEAT_GUI_GTK and
> various gtk header folders included. I don't have those headers on my
> server, that's why GTK GUI is not used by configure...
>
> Any advice would be appreciated.

You are using an X server running on MS-Windows? I have had nothing but
problems with that. I haven't tried for years though. Can you run with
a native X server?

--
"After a few years of marriage a man can look right at a woman
without seeing her and a woman can see right through a man
without looking at him."
- Helen Rowland

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[L A Walsh]

On 2021/05/07 11:56, Bram Moolenaar wrote:

> You are using an X server running on MS-Windows? I have had nothing but
> problems with that. I haven't tried for years though. Can you run with
> a native X server?
>

I've never had problems with running X on Win. Have done
so since XP days, and still do so under Win7.

I use cygwin's 'X', but it supports glx/3D graphics accel as
well so even glx progs run fairly well.

Of course much depends on network speed as well, but
anything on a local connection w/gigabit speeds should
be fine. A 100Mb connection was easily fast enough for
editing/vim work.

Recompiling gvim on my linux box is on my todo list. Suse's
gvim implementation is slightly broken if you don't have
their version of perl installed since they refuse to use
dynamic loading for perl (they do for other langs but not
perl!). I tried to give them a patch a few years back to
put perl in the same group as python/ruby, et al. by only
trying to dynamically load it if the user used a perl feature,
but they refused -- which made their version useless for
text editing if you didn't have their perl version installed
(cuz vim wouldn't start).

Anyway, my vim is still in the 7.x era, I'll be interested
to see if the 8.x version works as well.

[Aleksandr Jakušev]

If I am not mistaken, the terminal functionality was added after version 8.  The rest of GVIM works more or less OK for me too.

If you use vim 7, it is very unlikely that you will see the issues I have.

[L A Walsh]

On 2021/05/07 11:56, Bram Moolenaar wrote:

> Aleksandr Jakušev wrote:
>
>
>> Which makes me thing that the problem is GUI/X server related. And true,
>> this does not happen in the console verion of vim. FYI, My X server is one
>> of the latest versions of vcxsrv running on Win 10.
>>

>> Any advice would be appreciated.
>>
>
> You are using an X server running on MS-Windows? I have had nothing but
> problems with that. I haven't tried for years though. Can you run with
> a native X server?
>

Finally got to trying an 8.x running on my Linux (SuSE) w/display
on Windows 7SP1 (64bit) using Cygwin's Xserver.

I guess vim isn't using the win10-only terminal functions since it is
working on Win7

For speed testing, I did a full ls listing of /usr/lib64 w/6917 entries and
used 'dd' to sync. In bash, I used it's time function (and format:
TIMEFORMAT="%2Rsec %2Uusr %2Ssys (%P%% cpu)" ).
ran the whole thing under " bash -c 'cmd'":

time bash -c 'ls --quoting-style=literal --show-control-chars
--color=always -lgG /usr/lib64|dd oflag=dsync'

So besides the color output in the terminal window (TERM=xterm-256color),
I got 2 timings:
1164+1 records in
1164+1 records out
596002 bytes (596 kB, 582 KiB) copied, 3.49621 s, 170 kB/s
3.51sec 0.04usr 0.05sys (2.60% cpu)

So about a 17 million baud equivalent (this is over my 8Gb ethernet link).



I'd try a different X-server and I assume you have a 1Gb wired connection?

Best of luck!