As title. I just faced a situation that I have to browse some large file (for human, not machine perspective) with around 10,000~50,000 lines. Is it possible to only load those line that can be seen from the current window? E.g. Line 9542~9596, and add/release lines when scroll. I expect that this will increase the performance largely.

  • 3
    @Quasímodo advise is on point. But to answer your question: No Vim doesn't have this kind of mechanism. Also usually you just browse/read files this long, you don't edit them so if that's your case you probably want to use something like less rather than vim
    – statox
    Apr 27, 2022 at 13:27
  • 2
    @Quasímodo: Thank you. I just found the culprit by following your advice. it's some treesitter plugin that caused the problem.
    – Kindred
    Apr 27, 2022 at 13:40
  • 1
    It's possible vim actually effectively does something close to what you say, especially when it doesn't need to look too far off-screen for syntax-related things. But plugins that want to read the whole buffer are going to struggle. Vim is supposed to be performant even on quite large files. Alternately, try ex or ed, which are supposed to be quite performant also, and avoid the screen bits. Then you can, say, 9542,9596print to see a section of the file.
    – D. Ben Knoble
    Apr 27, 2022 at 13:53

1 Answer 1


No. From the readfile function in fileio.c:

 * We allocate as much space for the file as we can get, plus
 * space for the old line plus room for one terminating NUL.
 * The amount is limited by the fact that read() only can read
 * up to max_unsigned characters (and other things).

Doing a strace -o logfile vim -u NONE largefile confirms that Vim will indeed entirely load the entire file by issuing as many read calls as necessary (you will find them right after the first chmod line).

...and add/release lines when scroll. I expect that this will increase the performance largely.

Not really. The only significant performance gain would be in the start up time, simply because initially only a window worth of lines would be read from disk into memory.

Assuming the file fits in memory (and yours is only a few MiB in size), once it is loaded, there is no performance penalty in keeping it there.

Sluggishness on large files may be caused by plugins, as you found out to be your case by running vim --noplugin largefile

  • 1
    Sad, I thought I remembered reading something about some kind of smart buffering. Obviously not.
    – D. Ben Knoble
    Apr 27, 2022 at 15:12
  • I wonder if this answer is confusing two different concepts: loading the entire file into memory vs drawing only a small part of that file at any given time (which is called lazy loading and indeed increases performance significantly). Maybe this is what is described as lazysize in :h todo.txt
    – r_31415
    Sep 24, 2022 at 23:40
  • @r_31415 Well, nobody would dispute that only a small part of the file is "drawn" at any given time: It's evidently the part that fits the window or framebuffer. All of the file is loaded into memory nonetheless, so indeed they are different concepts. I probably miss your point, mind to clarify?
    – Quasímodo
    Sep 25, 2022 at 12:19
  • As far as I know, this lazy loading thing has never been implemented in vim, which is why there are performance issues with very large files and syntax on.
    – r_31415
    Sep 25, 2022 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.