Почему я люблю Vim?

За его скорость. Он гораздо быстрее чем все современные IDE. Хотя нужно признать, что современные IDE имеют ряд других преимуществ. Например, мне до сих пор удобнее делать рефакторинг проекта в атоме.

В общем инструмент каждый выбирает сам для себя. В этой статье я хочу показать плюсы вима.

Возьмем какой-нибудь стандартный JSON файл. И откроем его в Vim.

Вместе со всеми плагинами Vim скушал 85Mb памяти.

Vim small file 85mb RAM

При этом если я запущу этот же файл в Vim без плагинов, то мне нужно будет всего 6.1Mb памяти.

Vim without plugins 6.1Mb RAM

Теперь давайте откроем этот же файл в других редакторах или IDE и посмотрим сколько памяти сожрут они.

Atom with 1.6kb JSON
Visual Studio with 1.6kb JSON
Sublime Text 3 with 1.6kb JSON
PyCharm with 1.6kb JSON

Вот график. Даже для того чтобы просто открыть файл размером 1.6Kb современные редакторы сьедают 1.5-6Gb оперативной памяти.

Возможно, вы скажете, что память сейчас не такой дорогой ресурс. И вполне можно этим пожертвовать. И я бы с вами согласился. Но не соглашусь.

Во-первых, сейчас не только редакторы, но вообще все программы используют какое-то сумасшедшее количество памяти. У вас кроме редактора/IDE в любом случае будет запущен браузер с его несколькими вкладками, и еще куча других программ. Не знаю как там у вас, но лично мне 32Gb памяти уже не хватает.

Во-вторых, требуется не только память, но и ресурсы процессора. В том же редакторе при любом действии у меня начинаются лаги и подтормаживания. Из-за этих небольших лагов работать очень неприятно.

Понятное дело, что показать это на примере довольно сложно.

Пример #2. Большой файл.

Но давайте, например, возьмем большой JSON файл. Ну, не сильно большой. Я вот нашел на гитхабе какой-то JSON на 189Mb.

Можете скачать его отсюда

Давайте попробуем открыть его.

Vim открыл его без каких-то проблем и любое взаимодействие с файлом происходит точно так же как и с небольшим файлом.

Atom открыл файл без проблем, но при этом немного притормаживая и нагрев процессор до 84 градусов. И я еще ничего не делал с файлом.

Sublime Text 3 открывал файл секунд пять.

Visual Studio открыл за пару секунд.

PyCharm не смог в принципе открыть этот файл. Он сказал, что файл слишком большой. Что? Серьезно? WTF? IDE которая сожрала 6Gb памяти не может просто ОТКРЫТЬ файл? А что мне делать, если в моем проекте вот так вот случайно оказался такой файл? Мне нужно искать другой редактор чтобы с ним работать? Really?

Ну да ладно, давайте теперь что-нибудь поделаем с этим файлом. Например, заменим все слова "Feature" на слово "blablabla".

В Vim это делается командой :%s/Feature/blablabla/g

Запускаем эту команду и засекаем сколько она будет выполняться.

Засечь мне к сожалению не удалось. Так как она выполняется быстрее, чем я могу нажать два раза за кнопку секундомера. Уж извините.

Давайте теперь попробуем сделать это в Atom.

В атоме, к сожалению, я не смог этого сделать. Он мне выдал ошибку, что я превысил что-то там.

Ну ладно, что ж поделать. Если я не могу в одной из самых мощных IDE заменить текст, то давайте попробуем сделать это в Sublime Text 3.

Запускаем. И ждем. Тут я уже смог запустить секундомер. И даже устал ждать.

Sublime делал замену 90 секунд.

Ну что, уж лушче так, чем вообще никак.

Очередь Visual Studio.

А она к сожалению отказалась работать со всем файлом. И заменила только 10000 первых результатов. И после чего кнопка "Find" заблокировалась. И что мне делать? Остальные вхождения я заменить не могу? А зачем было заменять первые 10000, если нельзя заменить остальные? Какой вообще в этом толк?

Ну, пробовать PyCharm мы не будем, так как он даже открыть файл не в состоянии.

ВЫВОД

А вывод вы и сами видите. Я еще раз хочу сказать, что это просто тест, и мы не работаем постоянно с такими файлами. Ну а что, если вам когда-нибудь в жизни хоть раз придется это делать?

Этот тест просто показывает одно. Все современные редакторы/IDE написаны на слишком высокоуровневых языках. С использованием слишком тяжелых фреймворков и библиотек. В современной реальности все считают, что время разработки намного важнее, чем скорость работы программы. И мы имеем то, что имеем.

Программа отжирает невероятное количество оперативной памяти, процессорного времени, но при этом нещадно тормозит и не способна справится с задачами.