How to edit multi-gigabyte text files? Vim doesn't work =(

104,077

Solution 1

If you are on *nix (and assuming you have to modify only parts of file (and rarely)), you may split the files (using the split command), edit them individually (using awk, sed, or something similar) and concatenate them after you are done.

cat file2 file3 >> file1

Solution 2

Ctrl-C will stop file load. If the file is small enough you may have been lucky to have loaded all the contents and just killed any post load steps. Verify that the whole file has been loaded when using this tip.

Vim can handle large files pretty well. I just edited a 3.4GB file, deleting lines, etc. Three things to keep in mind:

  1. Press Ctrl-C: Vim tries to read in the whole file initially, to do things like syntax highlighting and number of lines in file, etc. Ctrl-C will cancel this enumeration (and the syntax highlighting), and it will only load what's needed to display on your screen.
  2. Readonly: Vim will likely start read-only when the file is too big for it to make a . file copy to perform the edits on. I had to w! to save the file, and that's when it took the most time.
  3. Go to line: Typing :115355 will take you directly to line 115355, which is much faster going in those large files. Vim seems to start scanning from the beginning every time it loads a buffer of lines, and holding down Ctrl-F to scan through the file seems to get really slow near the end of it.

Note - If your Vim instance is in readonly because you hit Ctrl-C, it is possible that Vim did not load the entire file into the buffer. If that happens, saving it will only save what is in the buffer, not the entire file. You might quickly check with a G to skip to the end to make sure all the lines in your file are there.

Solution 3

It may be plugins that are causing it to choke. (syntax highlighting, folds etc.)

You can run vim without plugins.

vim -u "NONE" hugefile.log

It's minimalist but it will at least give you the vi motions you are used to.

syntax off

is another obvious one. Prune your install down and source what you need. You'll find out what it's capable of and if you need to accomplish a task via other means.

Solution 4

A slight improvement on the answer given by @Al pachio with the split + vim solution you can read the files in with a glob, effectively using file chunks as a buffer e.g

$ split -l 5000 myBigFile
xaa
xab
xac
...

$ vim xa*
#edit the files

:nw  #skip forward and write
:n!  #skip forward and don't save 

:Nw  #skip back and write
:N!  #skip back and don't save

Solution 5

You might want to check out this VIM plugin which disables certain vim features in the interest of speed when loading large files.

Share:
104,077
Philip Brocoum
Author by

Philip Brocoum

Hello! I'm Philip, and I started developing for the web using Ruby on Rails at a startup in NYC in 2007. Fast-forward ten years and here I am in Portland where I lead all development at Syncta as our Sr. Engineering Manager. Syncta is a startup that was recently acquired by Watts Water Technologies. It's a true startup environment, so I don't just use Ruby — I do everything: DB & server administration and deployment, cloud scaling and automation, security, and project management. My passion has always been to build great products with great technologies.

Updated on January 11, 2020

Comments

  • Philip Brocoum
    Philip Brocoum over 4 years

    Are there any editors that can edit multi-gigabyte text files, perhaps by only loading small portions into memory at once? It doesn't seem like Vim can handle it =(

    • darjab
      darjab almost 15 years
      I've loaded really big data acquisition files in vim, and it handled them without problem.
    • El Yobo
      El Yobo almost 14 years
      Depending on your editing needs, you may just be able to pipe it through something like sed or perl to do a search and replace.
    • Sławomir Lenart
      Sławomir Lenart over 7 years
      Actually it's not off-topic, many programmers use vim, sometimes as a complement to UI editor. Topic question is about real problem. We all know only two such good swiss army tools for this kind of task, so please do not treat vim as too exotic or off-site. SO is for people.
    • Nike
      Nike over 4 years
      Instead of closing it, why not move it to SuperUser or Linux/Unix, or VIM ?
  • dkretz
    dkretz almost 15 years
    Usually sed is your friend in cases like this. Your editor really doesn't like the thought of inserting a few characters at the top of a file and figuring out how to push everything else down.
  • Jedihomer Townend
    Jedihomer Townend almost 15 years
    @le dorfier: Yep. I used sed when I had to do a search / replace. When I had to delete a few lines from a file like that (a few insanely long lines) I managed to do it in vim, but as you can guess moving between lines (as well as the actual deletion) took quite a bit of time (seconds+ to respond and redraw). I wouldn't want to attempt adding even a few letters to one of those lines.
  • Claes Mogren
    Claes Mogren about 13 years
    Great tip. I had a 13GB (152.000.000 lines) sql-file, and just using "split -l 1000000" then editing the one million line files where I wanted with vim worked great. Took 10 minutes just to split them. (I tried to open the original file with vim and that worked, but it was too slow to be usable.)
  • Totor
    Totor about 11 years
    This still loads the whole file in RAM...
  • michael
    michael about 11 years
    @Totor yeah I would split the file first but that setting would quickly give you the best vim performance by turning off random autocommands. That was my point. Workstations with decent memory should be able to handle files approaching a gig.
  • vancan1ty
    vancan1ty over 10 years
    Was able to deal with 44 gigabyte wikipedia xml dump in vim using this advice. (ctrl-c).
  • slawek
    slawek over 10 years
    Tried to read the end of 2.5GB log file on windows. Opening in gvim resulted in out of memory error when it exceeded 2GB memory allocated. When trying ctrl-c trick, it did stop loading the file into memory but only allowed to see the part of the file that gvim was able to load. So the longer I waited before pressing ctrl-c the more of the file I could see. Navigating to the end of file or loading rest of the file was impossible (or I didn't know how). Kinda disappointing that vim wasn't up to the task : ( In the end I used some free dedicated tool to split the file into 100MB files.
  • Aaron R.
    Aaron R. over 10 years
    I have to admit I don't exactly understand this case, but I just tested with vi and vim on Linux: if I press ctrl-C immediately after opening the file, I can see all the lines. If I wait a few seconds, though, it does just what you are saying @slawek. Guess I'm impatient. I would try that in gvim; I bet it has the same results.
  • Alexandre Lavoie
    Alexandre Lavoie almost 10 years
    That is the way to go, far better than splitting the file!
  • Hubro
    Hubro over 9 years
    The CTRL+C trick doesn't work for me. I open the file, GVim freezes, I press CTRL+C and it just says "Interrupted". It doesn't matter if I wait one second or 2 minutes. The file is a 500 MB Json file.
  • Aaron R.
    Aaron R. over 9 years
    My bet is it's the syntax-highlighting that's causing it to take so long; gVim doesn't usually struggle that hard for a 500meg file for me. I would suggest disabling the plugins like @michael suggests. A way to do it once you've already opened the file is to CTRL+C, then :syntax off, then :edit to reload the file. HTH
  • Kyle Strand
    Kyle Strand over 9 years
    @Hubro Vim may be waiting for you to hit "Enter" or something. The "Interrupted" message indicates that you've successfully prevented loading the entire file, I think.
  • Patryk
    Patryk over 9 years
    Doesn't work for me. I load a 3GB file, press ctrl-c and then the contents show up. I can edit scroll etc but when I get to the end of loaded part (let's say 5%) it won't load anymore (I am stuck with the part of file that loaded initially up to the point that I pressed ctrl-c)
  • EBarr
    EBarr about 9 years
    Exact same issue.... a "using" statement at the top of a SQL script for a large table, or a file group that doesn't exist in the target system. I use Free File Splitter to bust them up, the the command line below to rejoin.
  • user3338098
    user3338098 almost 9 years
    so vim/vi is useless when the file is 10 times the size of virtual memory?
  • Aaron R.
    Aaron R. almost 9 years
    Confirmed, user3338098. If you press Ctrl-C and it doesn't load the whole file (as others have talked about), saving it only saves what you have loaded. That's probably why it goes into readonly in the first place. I'll update my Readonly point to note that.
  • user674669
    user674669 almost 9 years
    I used this command to open a 250MB file in under 2 seconds. Amazing
  • Neobyte
    Neobyte over 8 years
    Following these instructions caused me to destroy a huge file I had just downloaded. You need to completely remove point 2 as it basically gives instructions that cause data loss, which you don't mention until the end of the post.
  • Shadow
    Shadow almost 8 years
    I'd be interested to know how they tested that... :P
  • Seperman
    Seperman over 7 years
    Why would you even partially load a file in vim and then accidentally overwrite it and lose the rest. Just use less or something like that which loads it partially anyways.
  • hhh
    hhh over 6 years
    How can you disable the plugin? Eg getting all other extensions such as highlighting to work again when a file is open in Vim?
  • elig
    elig almost 5 years
    On linux I recommend hexedit
  • Wojciech Adam Koszek
    Wojciech Adam Koszek almost 4 years
    This method corrupts the file. If you load 50% of content and save, you will truncate your file. Someone should remove this answer.
  • Eric Leschinski
    Eric Leschinski over 3 years
    If the file being opened has a line over 10-100 megabytes on a single line, then vanilla vim with the vim -u NONE hugefile.log will still hang for 30 or 90 seconds as the C under the hood inflicts set wrap upon the buffer. Remedy this by setting set nowrap before you open the file. Command :help wrap gives clues.