I have a 100MB MySQL database backup file and I have trouble to open it in Vim on my Linux box that has 16G of RAM.

Vim just hangs (at least unusable). This is something I don't understand. I have 16 GB RAM, why can't I load a 100 MB file in an editor?

Is it because of Vim? I thought all the memory management is handled by the OS.

  • 3
    Consider using a HEX editor instead of a text editor to view such files. An example of hex editor with vi-like interface would be hexer.
    – Ruslan
    Commented Jun 26, 2014 at 6:19
  • 13
    Don't forget that RAM has not been what we run out of when we run out of memory for decades now. Memory is now virtualized; it is divided up into pages and those pages can be swapped to disk. The amount of memory allocated out of a process's address space and the amount of RAM consumed have very little to do with each other. When you run out of memory, you've run out of address space, not RAM. The best way to think of it is memory is disk space, each process gets a certain fixed amount of that space, and RAM is hardware that makes your disk faster. Commented Jun 26, 2014 at 13:43
  • 22
    @EricLippert Except that traditional disks are so slow (compared to RAM) that they are only suitable for storing the virtual memory pages that are not in active use. If a process hangs (or is at least unusable, as the OP put it) due to swap thrashing, it is precisely because RAM is what it has run out of.
    – depquid
    Commented Jun 26, 2014 at 15:08
  • 6
    @EricLippert running out of address space is only relevant on 32 bit systems today. I doubt that the user with 16G RAM will still use 32 bit PAE kernel instead of normal 64 bit one.
    – Ruslan
    Commented Jun 26, 2014 at 18:06
  • 3
    @depquid: That is a good point; the thrust of my comment is that the OP seems to have the belief that "I loaded 100MB of stuff, I have 16000MB of RAM, so therefore 100MB of my 16000MB of RAM was consumed". This belief system is outdated. Commented Jun 26, 2014 at 18:31

8 Answers 8


Vim sometimes has trouble with files that have unusually long lines. It's a text editor, so it's designed for text files, with line lengths that are usually at most a few hundred characters wide.

A database file may not contain many newline characters, so it could conceivably be one single 100 Mb long line. Vim will not be happy with that, and although it will probably work, it might take quite a long time to load the file.

I have certainly opened text files much larger than 100 Mb with Vim. The file doesn't even need to fit in memory all at once (since Vim can swap changes to disk as needed).

  • 1
    I also noticed the very long lines, tried with another file without very long lines, see a big improvement. Thanks Commented Jun 26, 2014 at 2:15
  • 11
    @AskandLearn Depending on the file type, you may see a performance increase if you set synmaxcol=120 (or some other appropriate number). I've noticed huge speedups from this in the past.
    – sapi
    Commented Jun 26, 2014 at 7:30
  • Does anyone know if the recent neovim fork will handle longer lines better? I guess it isn't a particularly common issue...
    – Hemmer
    Commented Jun 30, 2014 at 12:39
  • @GregHewgill it's true, I've also observe that, but how did you know that ? Commented Jul 2, 2014 at 5:37

In my experience Vim chokes not on large files, but on long lines. Use this command to have mysqldump use shorter lines at the expense of a larger file:

$ mysqldump --complete-insert -u -p

Additionally, you can open Vim and ask it not to parse your .vimrc file or load any plugins with this command:

$ vim -u NONE output.sql

Loading Vim in this manner will use less memory and not require Vim to parse the entire file as many plugins do.


"load VIM without .vimrc and plugins (clean VIM) e.g. for HUGE files

  gvim -u NONE -U NONE -N largefile.sql

Try using less instead of vim if you want to view a large file directly. Vim tries to do a lot of different stuff when it first loads - scanning the file (potentially in multiple passes) to try to determine what syntax to use, and performing syntax highlighting, and searching for modelines at the top and bottom of the file. Then as you edit the file, vim is saving swapfiles and keeping undo trees (undo history in vim is branching, not linear like in every (?) other editor), and constantly re-evaluating the syntax highlighting as the text changes, etc.

None of that is necessarily a justification for why it must be so unusable with giant files, but it's more of an explanation of some of the reasons why it is.

  • See my answer for how to prevent VIM from performing the heavy operations such as file parsing.
    – dotancohen
    Commented Jun 26, 2014 at 8:52
  • Yup, syntax highlighting on things like XML and SQL can get very slow on larger files.
    – Marcin
    Commented Jun 26, 2014 at 15:02

Vim does not just load the file as-is into memory. It converts it into internal structures (lines, words, etc), performs syntax highlighting using an internal script language, and so on; all of which consumes memory (a whole lot more than a byte for a character) and CPU time.

  • Consuming memory is not even the issue. CPU time being taken up (and a visible freeze whilst you wait), is. Commented Jun 29, 2014 at 21:07
  • That CPU time is mostly taken up by the syntax highlighting script.
    – demonkoryu
    Commented Jul 1, 2014 at 8:45
  • Yes, I agree. I'm just saying that memory usage is very unlikely to (a) be a problem, or (b) cause a long delay, contrary to what your answer says. Commented Jul 1, 2014 at 8:54
  • You're right, I've updated my answer accordingly.
    – demonkoryu
    Commented Jul 2, 2014 at 8:19

You may try loading it as a binary. I've had luck with that for really big, non-text files


It's also possible IIRC to use vim as a hex editor see: http://usevim.com/2012/06/20/vim-binary-files/


Hopefully your problem is more to do with VIMs need for temporary files (such as swap) more than RAM.

In many cases, the temporary files created by VIM are in the same directory of the file you are opening. If this is the case for you, then you can verify by checking the available disk space in the current directory.

Fortunately, there is good documentation on how you can specify a different location for VIM's indexing/swap files:

You can also disable the swap file


I occasionally open large database backups in .sql text format. Very large files, or files with very long lines often sometimes seem to take a long time to open in vim. This might be related to syntax processing and colour highlighting, as mentioned in answers by @zzapper and @demonkoryu.

A quick workaround might be to press "control-G" during loading of the file to cancel the syntax highlighting pre-processing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .