Can 'Vim' Open a Large File in Read Only Mode as Fast as 'Less'

can 'vim' open a large file in read only mode as fast as 'less'?

Try starting vim without plugins:

vim -u NONE

You might also want to consider other options outlined here.

Alternatively, consider removing portions of log files before opening up in an editor. Try using ack instead of grep. The -Q option makes ack treat the pattern as a literal and should be considerably faster (similar to grep -F).

awk -Q pattern huge-file | vim -

Prefixing the above command with LANG=C might help if you're using UTF-8 locale.

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

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

Text editor to open big (giant, huge, large) text files

Free read-only viewers:

• Large Text File Viewer (Windows) – Fully customizable theming (colors, fonts, word wrap, tab size). Supports horizontal and vertical split view. Also support file following and regex search. Very fast, simple, and has small executable size.
• klogg (Windows, macOS, Linux) – A maintained fork of glogg. Its main feature is regular expression search. It supports monitoring file changes (like tail), bookmarks, highlighting patterns using different colors, and has serious optimizations built in. But from a UI standpoint, it's rather minimal.
• LogExpert (Windows) – "A GUI replacement for tail." It's really a log file analyzer, not a large file viewer, and in one test it required 10 seconds and 700 MB of RAM to load a 250 MB file. But its killer features are the columnizer (parse logs that are in CSV, JSONL, etc. and display in a spreadsheet format) and the highlighter (show lines with certain words in certain colors). Also supports file following, tabs, multifiles, bookmarks, search, plugins, and external tools.
• Lister (Windows) – Very small and minimalist. It's one executable, barely 500 KB, but it still supports searching (with regexes), printing, a hex editor mode, and settings.

Free editors:

• Your regular editor or IDE. Modern editors can handle surprisingly large files. In particular, Vim (Windows, macOS, Linux), Emacs (Windows, macOS, Linux), Notepad++ (Windows), Sublime Text (Windows, macOS, Linux), and VS Code (Windows, macOS, Linux) support large (~4 GB) files, assuming you have the RAM.
• Large File Editor (Windows) – Opens and edits TB+ files, supports Unicode, uses little memory, has XML-specific features, and includes a binary mode.
• GigaEdit (Windows) – Supports searching, character statistics, and font customization. But it's buggy – with large files, it only allows overwriting characters, not inserting them; it doesn't respect LF as a line terminator, only CRLF; and it's slow.

Builtin programs (no installation required):

• less (macOS, Linux) – The traditional Unix command-line pager tool. Lets you view text files of practically any size. Can be installed on Windows, too.
• Notepad (Windows) – Decent with large files, especially with word wrap turned off.
• MORE (Windows) – This refers to the Windows MORE, not the Unix more. A console program that allows you to view a file, one screen at a time.

Web viewers:

• readfileonline.com – Another HTML5 large file viewer. Supports search.

Paid editors/viewers:

• 010 Editor (Windows, macOS, Linux) – Opens giant (as large as 50 GB) files.
• SlickEdit (Windows, macOS, Linux) – Opens large files.
• UltraEdit (Windows, macOS, Linux) – Opens files of more than 6 GB, but the configuration must be changed for this to be practical: Menu » Advanced » Configuration » File Handling » Temporary Files » Open file without temp file...
• EmEditor (Windows) – Handles very large text files nicely (officially up to 248 GB, but as much as 900 GB according to one report).
• BssEditor (Windows) – Handles large files and very long lines. Don’t require an installation. Free for non commercial use.
• loxx (Windows) – Supports file following, highlighting, line numbers, huge files, regex, multiple files and views, and much more. The free version can not: process regex, filter files, synchronize timestamps, and save changed files.

How do I read a text file of about 2 GB?

Try Glogg.
the fast, smart log explorer.

I have opened log file of size around 2 GB, and the search is also very fast.

Enabling syntax and syntax folding in vim with large C file makes completion slow

I'm guessing your completion is being adjusted by the syntax highlighting file. To see if this is the case, and make completion lean and fast regardless, try

:set complete=.

which will make completion only use the current file.

read more about the complete options with

:help 'complete'

Handle minified Javascript/CSS in Vim

The LargeFile plugin (also referenced by answers suggested in the comments) adapts many Vim options to make it faster when a huge file is loaded.

In your case, it's not so much the total file size, but the extremely large (single) line. I would call that a mutilation, even a bug, because it severely impacts editing (regardless of the editor). In my opinion, that should be changed so that there's no necessity to directly edit the resulting file, only the contributing source (with the short, readable lines), and to join them in the build process.

Your screenshot already shows the effect of :help 'synmaxcol'; the coloring stops somewhere. I'd usually recommend to reduce that further, but you've already reported problems with :syntax off, which is an even bigger hammer to wield.
The slowness (in syntax highlighting and otherwise) is usually caused by regular expressions that spend a long time digesting the line. These could be used by indent or fold expressions, for example.

:setlocal indentexpr= foldexpr=

might be worth a try. For further troubleshooting, setting 'verbose' to a high value and checking what's happening is a good idea.

For a good editing experience, it would be best to convert the long line to multiple shorter ones. A 'formatprg' specific to CSS, or alternatively a quick :substitute should do the job, and still keep the CSS syntax intact. If you don't want to persist that change, the original line could be stored and restored prior to saving. With :autocmd BufWrite{Pre,Post}, this could even be fully automated, but that implementation effort will only be worth it if you have to edit these files often, and no other solution is possible.

Why do Vim experts prefer buffers over tabs?

As ZyX said on #vim, this question sounds like "Why do Vim experts prefer tasty over warm?".

"Vim experts" don't prefer buffers over tabs: they use buffers as the file proxies they are and tab pages as the workspaces they are. Buffers and tab pages have different purposes so preferring one to the other makes no sense whatsoever.

The issue with buffers and tabs is one of confusion, caused by a combination of independent facts.

1. Most "modern" text editors and IDEs use a tab metaphor to represent loaded files. That metaphor acts as an information system — it shows the user what files are opened and their state — and as an interactive device — it allows the user to manipulate (reorder, select, close…) those opened files. Despite their many limitations, tabs are everywhere and people are used to them and expect them everywhere.

2. Vim introduced tab pages in 7.0 as a way for its users to create ad-hoc "workspaces". Nothing in their features, their specific options, their specific commands or their :help sections suggests that tab pages could or should be used as file proxies.

   Nothing except the name and the appearance of "tab pages", of course, which leads to much confusion.

3. Without :set hidden, which is disabled by default and not very easy to find, Vim makes it impossible to switch to another buffer without writing the current one or abandoning its changes. New users, unaware of that option, have no choice but to turn to heavy windows use or to the closest "tab-like" feature they can find: tab pages.

"Tab page" is an unfortunate name choice for that feature, especially in an era dominated by the idea that reading documentation is a waste of time.

In Vim, tab pages are an abstraction built on top of windows, themselves an abstraction built on top of buffers. Each new level adds useful features but restricts your workflow.

The "buffer way"

With a buffer-based workflow, the files you are working with are distributed along a single dimension. You can cycle through your buffers, you can access a specific buffer by typing part of its name (with completion) or its number, you can alternate between buffers, you can target them pretty easily. There's basically no friction.

1. Eight buffers open, only one visible:

   

2. Switching by number:

   

3. Switching by name:

   

Buffers are Vim's file-proxies. If you think in terms of files, you think in terms of buffers.

The "window way"

With a window-based workflow, your "files" are both distributed along the same single "virtual" dimension as they would if you only used buffers and along two other "physical" dimensions. But the cartesian spaces in which those dimensions are found are almost completely separated: moving to another buffer still means "moving to another file" but moving to another window doesn't. The buffer that corresponds to the desired file may be displayed in that window but it could also be displayed in another one, maybe in another tab page, or not at all.

With windows, navigating between open files either becomes too complex or too simplistic, even with 'switchbuf' and :sb. Mostly because you are forced to use two sets of commands for what is essentially the same thing: accessing a buffer.

Windows have their use, as described below, but they don't have what it takes to replace buffers in anybody's workflow.

Here I am working on a Vim colorscheme. The two windows are different views of the same buffer: the top one serves as reference, with a table of the color codes used in the colorscheme, and the bottom one is where I work:

Windows are not designed as file-proxies and can't be made into ones: they are "containers" or "viewports" designed to offer you a view into a buffer. No more, no less.

The "tab way"

With a tab-based workflow, you essentially try to mimic the user experience you are used to from your previous editor while completely ignoring the very nature of Vim's tab pages. If we forget for a moment that this strategy is generally very unproductive, it is also impossible, just like with windows, to force Vim to adhere to that "one file = one tab" paradigm without losing a lot of flexibility.

Still working with the same files as above, the tabline takes up a significant space for virtually no benefit. All my files and all my tabs are called javascript*.vim so I can't do 3gt and be confident I'll end up at the right place and it is impossible to reach a specific tab by name. Add to that the fact that its label can very well be the very unhelpful but perfectly logical [Quickfix List]… Since there is no practical way to tie a file/buffer to a tab page, you are basically left with only one practical way to navigate between tab pages/buffers/files: cycling.

And yeah, my tabline is clobbered with only 8 tabs, imagine if I had 20!

1. Eight buffers open in eight tab pages (wrong)

   

2. Two tabs for two specific tasks (right)

   

Tab pages are "containers" or "viewports" designed to contain one or more windows, themselves also "containers" designed to contain buffers.

In conclusion

"Vim experts" (let's assume I can speak as if I was one) don't prefer buffers over tabs: they just use Vim as it was designed and are perfectly comfortable with that design:

• "Vim experts" have 2, 30 or 97 buffers loaded and are very happy they don't have to deal with spatial distribution;

• when they need to compare two files or work in one part of the current buffer while keeping another as a reference, "Vim experts" use windows because that's how they are meant to be used;

• when they need to work for a while on a separate part of the project without messing with their current view, "Vim experts" load a brand new tab page.

How to improve emacs performance when view large file?

To help with large files, I've installed my own find-file-hook which turns on fundamental mode (avoids font-lock), turns off undo, and makes the buffer read-only just to avoid any accidental changes (making unnecessary backups of large files).

(defun my-find-file-check-make-large-file-read-only-hook ()
  "If a file is over a given size, make the buffer read only."
  (when (> (buffer-size) (* 1024 1024))
    (setq buffer-read-only t)
    (buffer-disable-undo)
    (fundamental-mode)))

(add-hook 'find-file-hook 'my-find-file-check-make-large-file-read-only-hook)

Obviously adjust the threshold value as you see fit.

---

Related Topics