GVim slow on Ubuntu 8.10
François Ingelrest
Anyone else using the latest Ubuntu 8.10? I've installed it this
week-end, and compiled the latest Vim as well (7.2.25).
I've been using Vim all the day, and the GUI version is quite slow.
Well, it's usable, but I can see the redrawing of the screen, it takes
maybe a bit less than 1 sec. for the whole screen when I scroll a page
down/up. The file itself is not that big (it's a LaTeX file, and is
around 70KB), and actually Vim in a terminal is way faster to redraw
the screen even when the size of the terminal is the same as my GUI
window. I'm wondering why, since generally it's the opposite.
Any suggestion?
François Ingelrest
Still no one else facing this issue? I've tried using "-u None" but I
get the same slowness. As I said, it's still usable, but quite
annoying.
Charles Campbell
moment; however, I haven't noticed any such slowness when I have.
Try
gvim -u NONE -U NONE
because you have at least two initialization scripts (.vimrc, .gvimrc).
Regards,
Chip Campbell
Tony Mechelynck
gvimrc, as well as the global plugins.
You (François) might try instead to load gvim in the normal manner, then
(immediately afterwards) check the output of ":scriptnames" for anything
unusual.
Or, which 'guifont' are you using? Something complex like Script? If you
are, try something simpler like LucidaTypewriter (how to set it will
depend on your Vim GUI flavour; for GTK2 it would be ":set gfn=Lucida\
Sans\ Typewriter\ 8" on my SuSE system.
Best regards,
Tony.
--
"Have you lived here all your life?"
"Oh, twice that long."
bill lam
I'm also using ubuntu 8.10 (but gnome un-installed). There is no
noticeable degradation the performance of gvim.
Did you check the graphic card driver working properly?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
François Ingelrest
On Mon, Nov 3, 2008 at 15:54, Charles Campbell
<Charles.E...@nasa.gov> wrote:
> Try
>
> gvim -u NONE -U NONE
>
> because you have at least two initialization scripts (.vimrc, .gvimrc).
The redrawing of the script is still quite slow, even without the
syntax highlighting (disabled by -u NONE -U NONE).
On Mon, Nov 3, 2008 at 16:06, Tony Mechelynck
<antoine.m...@gmail.com> wrote:
> You (François) might try instead to load gvim in the normal manner, then
> (immediately afterwards) check the output of ":scriptnames" for anything
> unusual.
I couldn't find anything strange and/or new.
> Or, which 'guifont' are you using? Something complex like Script? If you
> are, try something simpler like LucidaTypewriter (how to set it will
> depend on your Vim GUI flavour; for GTK2 it would be ":set gfn=Lucida\
> Sans\ Typewriter\ 8" on my SuSE system.
I'm using "Courier New". Actually I've almost always used this font
with Vim and never has any problem. Using the Lucida font doesn't
change anything, but in both cases, resizing the window is a real
pain...
On Mon, Nov 3, 2008 at 16:38, bill lam <cbil...@gmail.com> wrote:
> Did you check the graphic card driver working properly?
I'm using the Radeon driver (open-source for ATI cards). I could try
to install the fglrx proprietary driver, but the Radeon one seems to
be working fine. Actually, GVim is the only application where I have
these problems, everything else is working just fine.
François Ingelrest
<francois....@gmail.com> wrote:
> The redrawing of the script is still quite slow, even without the
> syntax highlighting (disabled by -u NONE -U NONE).
Sorry, I intended to say "screen" here, not "script".
Aljosa Mohorovic
wrote:
> > Did you check the graphic card driver working properly?
>
> I'm using the Radeon driver (open-source for ATI cards). I could try
> to install the fglrx proprietary driver, but the Radeon one seems to
> be working fine. Actually, GVim is the only application where I have
> these problems, everything else is working just fine.
not available) and i'm having the same experience when i use gvim.
since i'm using gvim under kde4 and i had other problems with radeon
driver i'm blaming driver for gvim problems.
Aljosa
François Ingelrest
<aljosa.m...@gmail.com> wrote:
> i'm also using ubuntu 8.10/radeon open source drivers (since fglrx is
> not available) and i'm having the same experience when i use gvim.
> since i'm using gvim under kde4 and i had other problems with radeon
> driver i'm blaming driver for gvim problems.
Feels good not to be alone :-)
I've just installed and enabled the fglrx driver (which is in the
repos), and that doesn't make any difference. Redrawing the screen is
as slow with both drivers.
Anton Sharonov
2008/11/3, François Ingelrest <francois....@gmail.com>:
Dominique Pelle
I'm running Ubuntu-8.04 (I still haven't upgraded to 8.10) and
both vim & gvim seems fast enough. But fast or slow is
suggestive. So I just wrote a simple script to benchmark the
redraw speed and measured it with gvim as well as vim in
xterm and gnome-terminal:
Here is the benchmark script:
--- 8< --- cut here --- 8< --- cut here --- 8< ---
$ cat test-redraw-speed.vim
" Benchmark vim's redrawing speed
let i = 0
while i < 2000
1
redraw
$
redraw
let i = i + 1
endwhile
qa!
--- 8< --- cut here --- 8< --- cut here --- 8< ---
For the test, I made vim redraw the content of the file
vim7/src/README.txt. I ran the test with vim in a xterm,
in a gnome terminal and with gvim as follows:
$ time vim -u NONE -U NONE -S test-redraw-speed.vim vim7/src/README.txt
$ time gvim -u NONE -U NONE -f -S test-redraw-speed.vim vim7/src/README.txt
And here are the results below using my Linux x86 laptop
[Intel(R) Core(TM) Duo CPU T2250 @ 1.73GHz].
With vim-7.2.26 (huge, GTK2-GNOME GUI):
real user sys
------------------------------------- ------ ------ ------
vim-7.2.26 in xterm ................. 2.312s 0.968s 0.072s
vim-7.2.26 in gnome-terminal ........ 12.469s 0.972s 0.080s
gvim-7.2.26 ......................... 7.715s 5.800s 0.140s
With vim-7.1.138 (that comes with Ubuntu-8.04, GTK2-GNOME GUI):
real user sys
------------------------------------- ------ ------ ------
vim-7.1.138 in xterm ................ 2.320s 1.120s 0.088s
vim-7.1.138 in gnome-terminal ....... 15.384s 0.996s 0.056s
gvim-7.1.138 ........................ 26.614s 25.014s 0.376s
Interestingly, gvim-7.2.26 which I compiled myself is 3.44 times
faster than gvim-7.1.38 which comes with Ubuntu-8.04, at least
in this benchmark.
It would be interesting to compare with your results using
the same benchmark.
-- Dominique
François Ingelrest
> And here are the results below using my Linux x86 laptop
> [Intel(R) Core(TM) Duo CPU T2250 @ 1.73GHz].
>
> With vim-7.2.26 (huge, GTK2-GNOME GUI):
>
> real user sys
> ------------------------------------- ------ ------ ------
> vim-7.2.26 in xterm ................. 2.312s 0.968s 0.072s
> vim-7.2.26 in gnome-terminal ........ 12.469s 0.972s 0.080s
> gvim-7.2.26 ......................... 7.715s 5.800s 0.140s
>
>
> With vim-7.1.138 (that comes with Ubuntu-8.04, GTK2-GNOME GUI):
>
> real user sys
> ------------------------------------- ------ ------ ------
> vim-7.1.138 in xterm ................ 2.320s 1.120s 0.088s
> vim-7.1.138 in gnome-terminal ....... 15.384s 0.996s 0.056s
> gvim-7.1.138 ........................ 26.614s 25.014s 0.376s
Here are my results (Vim 7.2.25, default features, GTK2 support) on my
laptop (Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz):
GVim:
gvim -u NONE -U NONE -f -S test-redraw-speed.vim
~/Install/Vim/src/README.txt 9.12s user 0.28s system 2% cpu 6:41.49
total
Gnome-terminal:
vim -u NONE -U NONE -S test-redraw-speed.vim
~/Install/Vim/src/README.txt 0.75s user 0.06s system 2% cpu 35.531
total
Xterm:
vim -u NONE -U NONE -S test-redraw-speed.vim
~/Install/Vim/src/README.txt 1.95s user 0.07s system 22% cpu 9.147
total
Xterm doesn't use the same font as Gnome-terminal, so I don't think
the difference between them is that significant at the end. And yes,
it really took 6:41 to run the benchmark with GVim :-) I wasn't doing
anything else during the test...
bill lam
I do not have gnome terminal installed so only tested on xterm
$ time gvim -u NONE -U NONE -f -S test-redraw-speed.vim vim7/src/README.txt
real 0m53.115s
user 0m8.401s
sys 0m0.308s
$ time vim -u NONE -U NONE -S test-redraw-speed.vim vim7/src/README.txt
real 0m11.365s
user 0m1.524s
sys 0m0.112s
vim 7.2 patch 1-13 ubuntu 8.10 amd64 nvidia
Dominique Pelle
Those are strange results. You have a faster processor (2.16 Ghz
core2 vs 1.73Ghz core2) and yet redraw in gvim is about 52 times
slower than on my laptop (6min 41.49s vs 7.715s)!?
But only 9.12s was spent in gvim out of the 6min 41 sec, if I understand
your numbers correctly. So most of the time may be spent in the x-server
I suppose (what else?) How about running top in another terminal while
running the benchmark to see which process is really the CPU? On my
PC, gvim takes about 75% of the CPU and Xorg takes 21% (total is
more than 100% because I have 2 cores).
My hardware:
- video: nVidia G70 [GeForce Go 7600] 1440x900 pixels
nVidia driver version: 169.12
X.Org X Server 1.4.0.90
- cpu: Intel(R) Core(TM) Duo CPU T2250 @ 1.73Ghz
- RAM: 1Gb
I will probably upgrade Ubuntu 8.04 -> 8.10 next weekend, and
I'll run the same benchmark again.
-- Dominique
Kazuo Teramoto
<dominiq...@gmail.com> wrote:
> Those are strange results. You have a faster processor (2.16 Ghz
> core2 vs 1.73Ghz core2) and yet redraw in gvim is about 52 times
> slower than on my laptop (6min 41.49s vs 7.715s)!?
strangeness++;
*urxvt with screen*:
vim -u NONE -U NONE -S test-redraw-speed.vim 1.80s user 0.10s system
13% cpu *13.995* total
urxvt without screen:
vim -u NONE -U NONE -S test-redraw-speed.vim 1.80s user 0.11s system
3% cpu 1:03.07 total
xterm with screen:
vim -u NONE -U NONE -S test-redraw-speed.vim 2.04s user 0.15s system
1% cpu 1:53.05 total
xterm without screen:
vim -u NONE -U NONE -S test-redraw-speed.vim 2.12s user 0.12s system
2% cpu 1:36.51 total
linux console(uvesafb) with screen:
vim -u NONE -U NONE -S test-redraw-speed.vim 2.21s user 0.135s
system 3% cpu 59.707 total
*linux console(uvesafb) without screen*:
vim -u NONE -U NONE -S test-redraw-speed.vim 2.15s user *51.62s*
system *94%* cpu 56.711 total
My vim binary is compiled with +X11. Same fonts and geometry on urxvt
and xterm. Processor is a AMD Turion 1.8GHZ (single core). I have a
binary compiled without X11 and the results are the same. On every
test inside X the X cpu usage go to 90%. My linux distro is Arch Linux
with vim 7.2.25.
I repeated the test many many times to the same results.
Looks like urxvt+screen make a pact to work together...
--
«Dans la vie, rien n'est à craindre, tout est à comprendre»
Marie Sklodowska Curie.
Tony Mechelynck
Since the Linux console has no connection to the X server, in that
terminal you can speed up Vim startup considerably by using the -X
command-line switch.
Even in Console mode, Vim compiled with +x11 will try to connect to the
X server at startup because it still uses X for the +clipboard and/or
+clientserver features, to save and restore the console window title,
its contents (+xterm_save), and to "save itself" at X-windows closedown
(+xsmp or +xsmp_interact).
Best regards,
Tony.
--
It's odd, and a little unsettling, to reflect upon the fact that
English is the only major language in which "I" is capitalized; in many
other languages "You" is capitalized and the "i" is lower case.
-- Sydney J. Harris
Matt Wozniski
I'm not sure I follow - what does this have to do with his results? X
connection or no X connection shouldn't affect the time spent
redrawing, and certainly not by 50 seconds.
~Matt
Tony Mechelynck
no X connection affects the time starting up, because Vim waits for its
connection with the X server to time out. This may or may not influence
the results shown above, depending on how they are collected (they will
if it is from invoking to exiting Vim) but it's always good to know.
Best regards,
Tony.
--
A Christian is a man who feels repentance on Sunday for what he did on
Saturday and is going to do on Monday.
-- Thomas Ybarra
Dominique Pelle
Adding -X to the test does not affect performances for me (but
I'm not affected by this "slow redraw" bug)
$ time gvim -X -u NONE -U NONE -f -S test-redraw-speed.vim vim7/src/README.txt
real 0m12.262s
user 0m10.233s
sys 0m0.236s
$ time gvim -u NONE -U NONE -f -S test-redraw-speed.vim vim7/src/README.txt
real 0m12.411s
user 0m10.465s
sys 0m0.196s
The difference is just noise.
What I see though, is that the locale significantly affects speed. My tests
so far were with a UTF-8 locale (eo_XX.UTF-8). en_US.UTF-8 gives the
same results, but if I set locale to "C", then redraw is significantly
slower (though not as bad as what reports François.
$ export LANG="C"
$ export LC_ALL="C"
$ time gvim -u NONE -U NONE -f -S test-redraw-speed.vim vim7/src/README.txt
real 0m38.200s
user 0m36.206s
sys 0m0.484s
I tried several times, results are consistent. Setting locale to C instead
of eo_XX.UTF-8 (or en_US.UTF-8) makes this benchmark more than 3 times
slower.
But it still does not explain the fact the redraw is 52 times slower
on François's computer than on mine, even though he seems to have
better hardware than mine.
-- Dominique
Matt Wozniski
>
> On 04/11/08 22:25, Matt Wozniski wrote:
>>
>> On Tue, Nov 4, 2008 at 3:48 PM, Tony Mechelynck wrote:
>>> Even in Console mode, Vim compiled with +x11 will try to connect to the
>>> X server at startup because it still uses X for the +clipboard and/or
>>> +clientserver features, to save and restore the console window title,
>>> its contents (+xterm_save), and to "save itself" at X-windows closedown
>>> (+xsmp or +xsmp_interact).
>>
>> I'm not sure I follow - what does this have to do with his results? X
>> connection or no X connection shouldn't affect the time spent
>> redrawing, and certainly not by 50 seconds.
>
> connection with the X server to time out. This may or may not influence
> the results shown above, depending on how they are collected (they will
> if it is from invoking to exiting Vim) but it's always good to know.
It might be good to know, but it's certainly not relevant to whatever
problem these people are seeing... My WAG is that they're seeing a
font rendering regression (Pango? Freetype?), since I can reproduce
this problem in Debian Unstable with GTK2-GNOME gvim (105 seconds for
Dominique's benchmark) but not with the X11-Motif gvim (14 seconds for
Dominique's benchmark) or xterm/screen (13 seconds). In GTK2 gvim, I
used "DejaVu Sans Mono 7", in the others I use
"-misc-fixed-medium-r-semicondensed--13-120-*-*-c-60-iso10646-1".
Yep - just tested, and sure enough... switching my xterm font to
DejaVu size 8 brings the Dominique's benchmark up to 94 seconds from
13.
~Matt
Dominique Pelle
Maybe the font explains it, but I tried the test again with several
fonts and gvim always performed the test in 12s or 13s seconds
on my laptop. I tried it by adding the line:
set gfn=Courier\ 10
I also tried...
set gfn=Courier\ 10
set gfn=Courier\ New\ 10
set gfn=Monospace\ 8
set gfn=Monospace\ 10
set gfn=MiscFixed
set gfn=RufScript\ 10
Even with a non fixed size font like "RufScript\ 10" the test with
gvim completes in ~ 12 seconds only. RufScript font is
available at http://hiran.in/blog/rufscript-font.
MiscFixed font is available at http://dominiko.livejournal.com/16547.html
-- Dominique
Matt Wozniski
>
> 2008/11/4 Matt Wozniski:
>>
>> ... My WAG is that they're seeing a
>> font rendering regression (Pango? Freetype?), since I can reproduce
>> this problem in Debian Unstable with GTK2-GNOME gvim (105 seconds for
>> Dominique's benchmark) but not with the X11-Motif gvim (14 seconds for
>> Dominique's benchmark) or xterm/screen (13 seconds). In GTK2 gvim, I
>> used "DejaVu Sans Mono 7", in the others I use
>> "-misc-fixed-medium-r-semicondensed--13-120-*-*-c-60-iso10646-1".
>>
>> Yep - just tested, and sure enough... switching my xterm font to
>> DejaVu size 8 brings the Dominique's benchmark up to 94 seconds from
>> 13.
>
> fonts and gvim always performed the test in 12s or 13s seconds
> on my laptop. I tried it by adding the line:
>
> set gfn=Courier\ 10
Slow for me with Courier 10 and Courier New 10 as well. Seems to be a
recent regression. I wonder which package, though... Kazuo Teramoto
said that he could reproduce it on Archlinux, and since Arch and
Debian Sid are two of the biggest rolling-release distros, it makes me
think that this is an upstream regression in one of the libraries, and
not a Debian/Ubuntu specific regression. If someone with Gentoo could
do an emerge world, it would probably help to confirm or refute that
theory...
~Matt
Tony Mechelynck
IIUC, "Fixed" is a bitmapped font while "DejaVu Sans Mono" and even
"Courier New" are TrueType or OpenType scalable fonts. That could indeed
make a difference. Try running GTK2 gvim with
set gfn=Misc\ Fixed\ Semi-Condensed\ 13
(which ought to be the same as in your Motif gvim) and see if it doesn't
redraw much faster than with DejaVu. (Of course, Fixed is uglier. You
can't have your cake and eat it, or for Dominique and François, the
butter and the cash for the butter.)
Best regards,
Tony.
--
"I'd love to go out with you, but I have to stay home and see if I
snore."
Kazuo Teramoto
>
>>> On Tue, Nov 4, 2008 at 3:48 PM, Tony Mechelynck wrote:
>>>> Even in Console mode, Vim compiled with +x11 will try to connect to the
>>>> X server at startup because it still uses X for the +clipboard and/or
>>>> +clientserver features, to save and restore the console window title,
>>>> its contents (+xterm_save), and to "save itself" at X-windows closedown
>>>> (+xsmp or +xsmp_interact).
Tomorrow I gone make more tests on linux console.
> It might be good to know, but it's certainly not relevant to whatever
> problem these people are seeing... My WAG is that they're seeing a
> font rendering regression (Pango? Freetype?), since I can reproduce
Sorry, that test is not requested by I'm interested so I'm gonna post
than, if irrelevantly ask and I stop. ^_^
I my previous test I used a scalable font now I'm using a fixed
("-misc-fixed-medium-r-semicondensed--13-120-*-*-c-60-iso10646-1")
urxvt without screen (fixed font):
vim -u NONE -U NONE -S test-redraw-speed.vim 1.87s user 0.09s system
2% cpu 1:06.64 total
urxvt with screen (fixed font):
vim -u NONE -U NONE -S test-redraw-speed.vim 1.97s user 0.08s system
14% cpu 14.145 total
gvim (scalable)(this value is minutes, my other results is in seconds):
gvim -u NONE -U NONE -S test-redraw-speed.vim 0.46s user 0.13s
system 26% cpu 2.243 total
gvim (fixed)(this value is in minutes):
gvim -u NONE -U NONE -c "set gfn=Misc\ Fixed\ Semi-Condensed\ 9" -S
0.46s user 0.14s system 34% cpu 1.714 total
PS. Somewhat 'time' is reporting results in a different format (but I
used a watch to confirm the results.)
Kazuo Teramoto
[...]
Remember that you cannot let the win lost the focus. In all test I
dont let this happen.
François Ingelrest
> It might be good to know, but it's certainly not relevant to whatever
> problem these people are seeing... My WAG is that they're seeing a
> font rendering regression (Pango? Freetype?), since I can reproduce
> this problem in Debian Unstable with GTK2-GNOME gvim (105 seconds for
> Dominique's benchmark) but not with the X11-Motif gvim (14 seconds for
> Dominique's benchmark) or xterm/screen (13 seconds).
I tried to compile GVim with Motif (benchmark: 3.7 secs) and with GTK
(benchmark: 8.2 secs), so that indeed looks like an issue with GTK2
and the way it renders the fonts (since GTK is way faster with the
same font). I also tried using the "fixed" font with GTK2, but I get
the same result as with courier new.
I tried GEdit and did not see any rendering slowness during a normal
usage, editing the same file as with GVim (syntax highlighting enabled
in both cases of course). I know they don't work in the same way, and
that a problem with Pango may be noticeable with GVim and not with
another editor, but could the problem specifically come from the way
GVim uses GTK2 to render text (instead of coming from Pango)?
Matt Wozniski
Seems unlikely to me, since I see the same slowdown in xterm when
using a Freetype font as I see in GTK2 gvim... vim has no control
over the rendering there, yet I see a significant performance hit.
~Matt
fREW Schmidt
Hi all,
Anyone else using the latest Ubuntu 8.10? I've installed it this
week-end, and compiled the latest Vim as well (7.2.25).
I've been using Vim all the day, and the GUI version is quite slow.
Well, it's usable, but I can see the redrawing of the screen, it takes
maybe a bit less than 1 sec. for the whole screen when I scroll a page
down/up. The file itself is not that big (it's a LaTeX file, and is
around 70KB), and actually Vim in a terminal is way faster to redraw
the screen even when the size of the terminal is the same as my GUI
window. I'm wondering why, since generally it's the opposite.
Any suggestion?
--
-fREW
François Ingelrest
> Make sure to check the output of top. For some reason on my laptop I have a
> process (ksoftirqd/0) that takes up a significant amount of the processor.
> I haven't seen anyone with a solution for it yet.
During Dominique's benchmark, Xorg takes around 97% of the CPU. GVim
is only around 2-3%.
John Little
Is this going anywhere, François?
On Nov 4, 9:53 pm, bill lam <cbill....@gmail.com> wrote:
> vim 7.2 patch 1-13 ubuntu 8.10 amd64 nvidia
Regards, John
François Ingelrest
>
> 2008/10/27 François Ingelrest <francois.ingelr...@gmail.com>:
>> Anyone else using the latest Ubuntu 8.10?
>>... the GUI version is quite slow.
>
> Is this going anywhere, François?
No, the issue is still there. As I said, GVim is usable, but it's
quite annoying to see that much the redrawing of the screen. As a
result, I've started to use only Vim in a terminal, which is way
faster and more pleasant.
Bob Hiestand
slowdown for gvim. This is presumably a fairly narrow set of
parameters which cause the problem.
John Little
On Nov 12, 5:10 pm, "Bob Hiestand" <bob.hiest...@gmail.com> wrote:
> fwiw, I'm running nvidia on a nearly stock ubuntu 8.10 with no
> slowdown for gvim. This is presumably a fairly narrow set of
> parameters which cause the problem.
EnvyNG (http://albertomilone.com/nvidia_scripts1.html) might install?
I needed this on Feisty and Hardy to get the 1680x1050 of my monitor.
Regards, John
Dominique Pelle
my laptop from Ubuntu-8.04.1 to Ubuntu-8.10.
Ubuntu-8.04.1, with vim-7.2.26 (huge, GTK2-GNOME GUI):
real user sys
------------------------------------- ------ ------ ------
vim-7.2.26 in xterm ................. 2.312s 0.968s 0.072s
vim-7.2.26 in gnome-terminal ........ 12.469s 0.972s 0.080s
gvim-7.2.26 ......................... 7.715s 5.800s 0.140s
Ubuntu-8.10, with vim-7.2.40 (huge, GTK2-GNOME GUI):
real user sys
------------------------------------- ------ ------ ------
vim-7.2.40 in xterm ................. 3.329s 0.948s 0.064s
vim-7.2.40 in gnome-terminal ........ 15.224s 1.524s 0.128s
gvim-7.2.40 ......................... 9.876s 6.256s 0.256s
I do not see a major slow down for me with Ubuntu-8.10 as
reported by original submitter, though I see a small slow down.
I repeated the measurements several times. I used the exact
same font and terminal size (80x24), same laptop. Version
of Vim is slightly different, but I don't think it matters.
-- Dominique