Вім павольна з сінтаксісам лал падсветкай

Я выкарыстоўваю Vim праз SSH, каб працаваць на працягу тыдня або двух, і ў цяперашні час усё ішло выдатна. Сёння я вырашыў дадаць у некаторай падсветцы сінтаксісу, аўтазапаўненне, а таксама некаторыя іншыя агульныя модулі. Настройка vundle і пайшоў працаваць.

Мой бягучы .vimrc можна знайсці на сайце https://github.com/scottopell /dotfiles/blob/master/.vimrc </спраў>

Я кланаваць мой vimrc і VIM файлы на маіх лакальных Ubuntu Desktop і VIM бяжыць дакладна так, як і чакалася, ня павольнасць на ўсе файлы, якія я не магу знайсці. Тыя ж убудовы і той жа vimrc і ня марудлівасць на лалавых файлы.

update

Я магу прайграць гэта пытанне з наступным .vimrc

syntax on

і пусты ~/.vim тэчка.

Аднак, Вім на гэтым VPS вельмі павольна з лалавымі/Haml файлаў. Шмат рубінаў файлаў у большай ступені ,. Калі я адкрыць любы файл лалавага, запуск займае каля 2 секунд (прымеркаваных з --startuptime). Пры супастаўным файла даўжыня Haml, яго каля 0,5 секунд. Гэтая павольнасць не толькі пры запуску альбо, рухаючыся вакол і рэдагавання файла абодва пакутліва павольна.

Haml/ERB (яны ў асноўным тое ж самае)

268.818  000.005: before starting main loop
848.871  580.053: first screen update

лал

199.613  000.004: before starting main loop
2937.859  2738.246: first screen update

Without syntax highlighting on the same лал file as above

149.047  000.004: before starting main loop
152.912  003.865: first screen update 

I have tried using mosh(http://mosh.mit.edu) and it doesn't help. not really relevant anymore

As you can see in my .vimrc file, I have tried a few different solutions to this problem. I have tried running with all plugins disabled (I moved them all from ~/vim/bundle/PLUGINNAME to ~/vim/bundle/disabled/PLUGINNAME, is this correct?), set лал path, set foldlevel to manual, disabled my colorscheme, nothing helps. see edit3

Я магу апублікаваць поўны справаздачу startupttime для любога файла, калі гэта дапаможа.
Я праверыў некалькі іншых моў (PHP, C, Python, VIML), і ўсе адчуваюць якіх-небудзь запаволення.


EDIT: Just to clarify, I am running an ssh session with ssh [email protected] then once inside the server I am doing vim file.rb.

EDIT2: I just tried accessing the server directly and the slowness persists without ssh, I have updated to reflect that this isn't a problem with ssh.

EDIT3: I can reproduce the issue with a .vimrc file that contains the single line syntax on with an empty ~/.vim folder

EDIT4 I uninstalled my compiled version of vim and any versions that I may have installed through apt, manually removed all vim stuff from my system, and I can run vim with vim -u NONE /path/to/file.rb then do :syn on and the issue will be there. The file in question is a rails controller, but like I've said, I can recreate it to some degree with most any file, but rails controllers see to be the worst.

38
што, калі вы ў рэальнай машыне? Час загрузкі з Vim не павінны ўплываць SSH, паколькі ён вылічае ўсе на кампутары і адправіць ўсю інфармацыю па сетцы толькі адзін раз.
дададзена аўтар fotanus, крыніца
@ScottO Праверце выкарыстання рэсурсаў на адным акне SSH (магчыма, з дапамогай каманды верхняга ) пры рэдагаванні Vim ў іншы і паглядзець, калі вы атрымаеце да канца.
дададзена аўтар fotanus, крыніца
Колькі радкоў у файлах, якія вы змяняеце?
дададзена аўтар Jim Stewart, крыніца
@ScottO Не маглі б вы, магчыма, паспрабаваць выдаліць ~/.viminfo файл? Абавязкова зрабіце рэзервовую копію першай, напрыклад, перамясціць яго ў ~/.viminfo.bak для тэставання. Калі ён не працуе, выдаліце ​​новаспечаны файл і перамясціць яго назад. <�Код> viminfo файл часам змяшчае дзівацтвы, якія цяжка растлумачыць.
дададзена аўтар timss, крыніца
Так як вы не атрымліваеце яго тут адказу, можа быць, спытаеце на # VIM @ Freenode, а таксама. Калі вы добра з дапамогай IRC, то ёсць. Калі вы знайшлі адказ на іншых каналах/сайтах, калі ласка, апублікаваць адказ тут. Поспехі, мне вельмі цікава, а таксама да таго, што гэта можа быць.
дададзена аўтар timss, крыніца
Як менавіта вы карыстаецеся Vim над SSH? Рэдагаванне файлаў лакальна або выдалена?
дададзена аўтар timss, крыніца
Паспрабуйце хай ruby_no_expensive = 1 у .vimrc і паглядзець, ці дапаможа гэта праблему прадукцыйнасці.
дададзена аўтар Don Cruickshank, крыніца
Вы можаце гуляць з : усталяваць ttyfast , і я лічу, што ёсць некалькі іншых параметраў, якія кантралююць затрымкі Намер UI
дададзена аўтар demure, крыніца
У мяне падобнае пытанне, лал/Haml файлы з вечна быць звернутыя (пры адкрыцці або пракруткі буфера) і загрузіць адзін ядро ​​майго працэсара да 100% на працягу дзясяткаў секунд. Бывала сёння пасля абнаўлення ўсіх пакетаў у сістэме Arch Linux ( pacman -Syu ). <�Код>: сін выключаны вырашае, але я збольшага выкарыстоўваецца для кветак у маіх крыніцах. : - /
дададзена аўтар dmedvinsky, крыніца
дададзена аўтар Derek Kraan, крыніца
@DonCruickshank Не дапамагло. Вім да гэтага часу выкарыстоўваюць вялікая колькасць цэнтральнага працэсара (50-90%) пры адкрыцці/рэдагаванні файла.
дададзена аўтар ScottO, крыніца
@fotanus зверху паказвае, што Вім выкарыстоўвае велізарная колькасць CPU пры адкрыцці файла і рэдагавання файла. Я бачыў у нейкі момант ён выкарыстоўвае 90% CPU. Ці значыць гэта што-небудзь для вас? Я не магу рабіць якія-небудзь высновы з яго, акрамя чагосьці ў Vim выкарыстоўвае шмат цэнтральнага працэсара, верагодная кампанент падсвятлення сінтаксісу.
дададзена аўтар ScottO, крыніца
@fotanus Скрынка пад пытаннем з'яўляецца digitalocean VPS, так што я выкарыстаў іх доступ да кансолі і паспрабаваў, праблема захоўваецца, робячы гэта, так што вы, здаецца, правільна, SSH не гуляе ролю ў праблеме
дададзена аўтар ScottO, крыніца
@demure Я проста паспрабаваў ttyfast без зменаў.
дададзена аўтар ScottO, крыніца
@timss я удакладнена на пасадзе, я рэдагую выдалена.
дададзена аўтар ScottO, крыніца
@timss Проста спрабаваў, выдаленне viminfo ня дапамагло, на жаль, так што я паклаў мой стары viminfo таму і выдаліў згенераваны адзін.
дададзена аўтар ScottO, крыніца
@JimStewart я магу ўзнавіць яго ў нейкай ступені з файламі любога памеру, але адзін я выкарыстоўваю для гэтых тэстаў 19 радкоў. Ні адна з ліній не вельмі доўга, верагодна, каля 30 калон або каля таго.
дададзена аўтар ScottO, крыніца
@JimStewart я памылілася, што файл 507C, некаторыя павінны быць прабелы, таму што гэта не выглядае так доўга. Я паспрабаваў ўсталяваць synmaxcol і што нічога не дапамагае.
дададзена аўтар ScottO, крыніца
Дэрэк Краа - Не думаю, гэтае пытанне было прайграваных з Вім -u NONE , гэта значыць, усе выключана. што праблема знікне, калі вы адключыце убудова. Акрамя таго, гэта адбылося пасля таго, як гэтая праблема была вырашана вышэй.
дададзена аўтар ScottO, крыніца

7 адказы

Рашэнне гэтай праблемы апынулася рэгулярны выраз рухавік, які Vim выкарыстоўвае. Спекуляцыі на #vim на Freenode з'яўляецца тое, што сінтаксіс файлы лал выкарыстоўваць нешта больш павольна новага рэгулярных выразаў.

Любая версія старэй і уключаючы Vim 7.3.969 мае стары рухавічок рэгулярных выразаў. Дадаць у усталяваны п = 1 у свой vimrc , каб прымусіць стары рухавічок рэгулярных выразаў на любой версіі навей (і не забудзьцеся перазагрузіць файл, які вы ў цяперашні час рэдагавання з дапамогай < код>: е ).

Дзякуючы Houl, Долио і dmedvinsky з #vim па дапамогу высветліць гэта.

У мяне не было магчымасці паспрабаваць самай апошняй версіі, быў здзейсніць мінулай ноччу, што можа дапамагчы з гэтым пытаннем. Я буду абнаўляць гэта, калі я атрымліваю шанец паспрабаваць крывацёк краю версію зноў.

87
дададзена
<�Б> Важнае заўвага : Для гэтага, каб працаваць, вы <�я> павінен </я> перазагрузіць файл, які вы рэдагуеце (: е )!
дададзена аўтар Doorknob, крыніца
Unfortunataly, ні адзін з адказаў на ўсе пытанні не працаваў для мяне. Я праверыў яго ці VIM -u NONE і чым ўручную дазваляе сінтаксіс. З'явілася праблема, таму ні адзін з маіх налад або пучкоў не выклікае праблему. Я выкарыстоўваю Vim 7.4, уключаныя патчы 1-273.
дададзена аўтар OrangeTux, крыніца
@BrianZitzow што пра набор regexpengine = 1 ?
дададзена аўтар mb21, крыніца
якія маюць адзін і той жа сімптом з Haml файлаў з кодам <> сінтаксісам і сённяшняй Вім праверкі. <�Код> усталяваны п = 1 фіксуе гэта! выглядае як новы регулярное_выражение рухавік павінен быць аптымізаваны?
дададзена аўтар Markus, крыніца
Так што гэта была памылка ў рэшце рэшт. Дзякуй за тое, што пацыент і ва ўсім з пост, каментары і адказваць!
дададзена аўтар timss, крыніца
Вы эканоміце мой дзень, дзякуй!
дададзена аўтар zx1986, крыніца
Выкарыстанне усталяваны п = 1 робіць Vim нават павольней для мяне. Любыя іншыя прапановы па гэтым пытанні?
дададзена аўтар netmute, крыніца
FWIW гэта, падобна, не абмяжоўваецца лал - Я выкарыстоўваю Vim 1287/03/07 з easytags убудова для пітона файлаў і заўважыў масіўную запаволенне пасля таго, як падкрэсліў тэгі - ўстаноўка паўторна 1 дапамаглі ў гэтым выпадку.
дададзена аўтар Wieland, крыніца
Гэта выкарыстоўваецца для працы, але цяпер я атрымліваю паведамленне пра памылку: E518: Невядомая опцыя: п = 1 Vim версіі: VIM - Vi IMproved 7.3 (2010 15 жніўня, складзены 27 кастрычніка 2015 16: 22:14)
дададзена аўтар Brian Zitzow, крыніца
@BrianZitzow, што падрыўныя вы? Як паказана ў посце, нічога старэй [ўключна] 7.3.969 не будзе мець гэты варыянт, таму што новы механізм рэгулярных выразаў быў дададзены ў праўцы 970 ( github.com/vim/vim/commit/… )
дададзена аўтар ScottO, крыніца
Што дакладная версія Vim вы карыстаецеся?
дададзена аўтар ScottO, крыніца
Я хацеў бы пачаць свой уласны пытанне або скакаць на Вім IRC-чат. Гэта была праблема, звязаная з пэўным дужа дыяпазонам версій VIM, так што ўсё тут, верагодна, не будуць мець адносіны да вашага пытання. Я на Вім 7.4a патч 1-6 і ўсё ў парадку, калі вы хочаце паспрабаваць розныя Вім версіі.
дададзена аўтар ScottO, крыніца
Так, новы Вім рухавічок рэгулярных выразаў не павінен неяк у сінтаксісе лал файлаў. Я не бачыў ніякіх праблем ні з якімі іншымі, чым лал моў (ці сінтаксісу, якія ўключаюць лал, такія як Еўрарадыё або Haml)
дададзена аўтар ScottO, крыніца

Вы павінны ўсталяваць гэта Tw варыянты ў вашым vimrc:

set ttyfast
set lazyredraw

Калі гэта не вырашае праблему паспрабаваць пачаць Vim без вашага vimrc, каб быць упэўненым, што ні адзін з вашых бягучых налад ня зашрубоўвання яго.

vim -u NONE
16
дададзена
Абсалютна не дзіўна! Цяпер я магу вярнуцца да VIM з Sublime, так як Вім пачаў працаваць значна хутчэй.
дададзена аўтар Artem Pyanykh, крыніца
Гэты фіксаваны павольны сінтаксіс Ruby, на Neovim, дзякуй!
дададзена аўтар tomswift, крыніца
Магчыма, вы адключылі кожны набор варыянт сам-насам? Я думаю, што лінія 25 можа быць ваша праблема
дададзена аўтар Denny Crane, крыніца
Ну ў гэтым выпадку ... Happy адладкі. Адключыць крок за крокам кожны убудова і опцыі, каб даведацца, што выклікае праблему.
дададзена аўтар Denny Crane, крыніца
Я дадаў гэтыя два да майго vimrc і нічога не дапамагае. Запуск без майго vimrc не фіксуе праблему, але як толькі я ўключаю сінтаксіс на яго спіне. Не зусім так дрэнна, як і раней, але, безумоўна, ёсць нешта прыкметна не так.
дададзена аўтар ScottO, крыніца
Я паспрабаваў адключыць усе, што я думаю, можа паўплываць на гэта. Line 25 не дапамагло. Я проста паспрабаваў выкарыстоўваць свежы файл .vimrc і ўсё, што я зрабіў сінтаксіс на і я магу ўзнавіць праблему.
дададзена аўтар ScottO, крыніца
Я паспрабаваў адключыць усе мае убудова з --noplugin перамыкачом, і гэта ўсё яшчэ адбываецца. Я таксама паспрабаваў апаражненне майго каталога убудова, праблема застаецца. Гэта тое, што я змагаюся з.
дададзена аўтар ScottO, крыніца

Дзве рэчаў, якія значна дапамогуць паскорыць Рубінавым падсвятленне сінтаксісу адключаюць лініі курсора і адносны нумар для ruby (калі вы выкарыстоўваеце тыя).

У мяне ёсць наступныя ў маёй .vimrc:

" ruby is an oddball in the family, use special spacing/rules
if v:version >= 703
  " Note: Relative number is quite slow with Ruby, so is cursorline
  autocmd FileType ruby setlocal ts=2 sts=2 sw=2 norelativenumber nocursorline
else
  autocmd FileType ruby setlocal ts=2 sts=2 sw=2
endif
12
дададзена
Абодва relativenumber і cursorline запавольвала працу для мяне. Я не магу, напэўна, абысціся без cursorline , але не relativenumber .
дададзена аўтар Kris, крыніца
Гэта быў cursorline для мяне - дзякуй!
дададзена аўтар chopper, крыніца
Калі вы хочаце захаваць relativenumber і cursorline сітуацыя можа быць палепшана з дапамогай набор lazyredraw . Гэта не вырашае праблему, але змякчыць запаволенасць курсора лініі highlightinga
дададзена аўтар Punkman, крыніца
Да! Дзякуй, гэта было relativenumber, што выклікала Вім быць настолькі павольным ў маім выпадку.
дададзена аўтар bemug, крыніца

Паспрабуйце ўсталяваць свой шлях рубінавы відавочна ў вашым vimrc:

let g:ruby_path="/usr/bin/ruby"
5
дададзена
У мяне ёсць Няхай G: ruby_path = '' на дадзены момант. Да таго часу, як вы вызначаеце гэта пераменны, вы атрымаеце перавага хуткасці.
дададзена аўтар Jerome Dalbert, крыніца
Гэта вельмі карысна. Акрамя таго, таму што я знайшоў, што гэта каштавала 2.4S шукаць шляхі Рубі з профілю: 1 2.426607 0,000126 Няхай G: ruby_default_path = ы: query_path ($ HOME)
дададзена аўтар Cam Song, крыніца
Я проста паспрабаваў ваш прапанаваць і мой варыянт, ні меў ніякага эфекту.
дададзена аўтар ScottO, крыніца
Я выкарыстоўваю RVM для рубіну, так што гэта тады будзе Няхай G: ruby_path = "~/.rvm/bin/лал" ?
дададзена аўтар ScottO, крыніца

Я выкарыстоўваю Vim 7.4.52 і ні адно з гэтых рашэнняў не працаваў для мяне.

Згодна з гэтым GitHub каментар па гэтым пытанні ( https://github.com/vim/ Вім/пытанні/282 # issuecomment-169837021 ), foldmethod = сінтаксіс адказвае за марудлівасці.

Даданне гэтага да маёй .vimrc нарэшце ўсталяваў яе!

augroup ft_rb
    au!
    " fix the SLOOOW syntax highlighting
    au FileType ruby setlocal re=1 foldmethod=manual
augroup END
4
дададзена
Гэта фіксуе неверагодна павольнае рэдагаванне рубіну файлаў я перажываюць, дзе нічога не рабіла. Імгненнае палягчэнне. Вялікае вам дзякуй!
дададзена аўтар omnikron, крыніца

см UPDATE у ніжняй часткі.

гэта можа быць карысна ў якасці абыходнага шляху -

Я выкарыстоўваю Vim версіі

<�Р> Вім - Vi IMproved 7.4 (2013 Aug 10, скампіляваны 2 студзеня 2014 19:40:46) </р>      <�Р> Уключаныя патчы: 1-52

гэта запас версія ад Linux Mint 17,1 Рэбека.

файл сінтаксісу php.vim ня version'd, што я магу бачыць, але гэта апошні edit'd ОЭЗ 28 13 жнів.

гэта не праект рубіну, але пры рэдагаванні вялікага класа PHP файла (

    $ PHP -w test.inc | wc
    2    2410   19220

) Я адзначыць значныя затрымкі ў верхняй частцы класа, але не вышэй або ніжэй класам, і, у прыватнасці, не ў ніжняй частцы класа. як я спроба ўставіць новы тэкст у ніжняй частцы класа, затрымка мінімальная і, здаецца, прапарцыйна колькасць ліній ўнутры класа. «Мінімальны» азначае амаль імгненна, «значны» азначае 1 да 1,5 секунд на знак.

файл прыблізна 1800 ліній з прыблізна 500 ліній легальнага PHP і 1300 радкоў каментароў і док. клас пачынаецца каля лініі 30 і заканчваецца прыблізна лініі 1700. ён саступаў гэта трохі вялікая, але добра задакументаваныя: - \

калі я ўставіць

    class dummy { }

перад арыгінальным «класа ORIGINALNAME {», няма ніякай затрымкі ў любым месцы файла. гэтая непрывабная Клюге дазваляе VIM/GVIM аднавіць сваю спагадлівасць і можа разглядацца як абыходны шлях. звярніце ўвагу, няма перакладу радкі паміж імі, проста

    class dummy { } class originalName {

яна нават можа быць comment'd з:

    /*class dummy {}*/class originalName {

Дадатковая інфармацыя:

  1. during this test, the plugins directory was moved.

  2. with "set syntax=off", the problem completely disappears. this is NOT a fix.

  3. setting the regular expression engine with

    set regexpengine=1   (or any other number)
    

    does not appreciably change the results.

на аснове гэтых вынікаў, я б западозрыць рухавічок рэгулярных выразаў, а таксама. мой пункт з'яўляецца тое, што diddling трохі з сінтаксісам ў лалавых файлах можа прывесці да абыходным шляху.

UPDATE: я знайшоў, што гэтае пытанне «выклікаў», усталяваўшы php_folding у 1 (уключана). vimrc я думаў, што я выкарыстаў не было, але, па меншай меры, некаторыя таямніцы вырашаецца з-за гэтай памылкі. просты vimrc, як гэта будзе выклікаць праблему (для мяне, як мінімум):

    :syntax enable
    :let php_folding = 1

гэта азначае, што маё пытанне не мае ніякага дачынення да пытання рубіну, але можа быць такім жа, што адбываецца з файлам ruby.vim. можа быць, няма.

прабачэнні за прагін.

1
дададзена

Я паспрабаваў большасць з гэтых рашэнняў, але тое, што ў канчатковым выніку працуе для мяне лепш было выдаленне любых убудоў, звязаных з авіякампаніяй.

0
дададзена
Я лічу, то гэта на самай справе праблема сінтаксісу. Нумар выпуску быў прадастаўлены ў пытанні авіякампаніі.
дададзена аўтар Christian Brabandt, крыніца
Паспрабуйце спачатку, калі адключыць падсвятленне сінтаксісу фіксуе яго.
дададзена аўтар Christian Brabandt, крыніца
Адключэнне сінтаксісу робіць гэта хутчэй, але я не зацікаўлены ў працы без сінтаксісу уключаны.
дададзена аўтар Uri, крыніца