Quirks: editing huge files is slow

This commit is contained in:
Marco Hinz 2016-01-09 14:26:05 +01:00
parent 9901e63949
commit 50cdf204d4
2 changed files with 27 additions and 0 deletions

View File

@ -10,6 +10,7 @@ All notable changes to this project will be documented in this file.
- Tips: [Saner command-line history](README.md#saner-command-line-history)
- Debugging: [Verbosity](README.md#verbosity)
- Debugging: [Debugging Vim scripts](README.md#debugging-vim-scripts)
- Quirks: [Editing huge files is slow](README.md#editing-huge-files-is-slow)
- Miscellaneous: [Easter eggs](README.md#easter-eggs)
## [1.1] - 2016-01-07

View File

@ -60,6 +60,7 @@ added every day. Things about to be added can be found here:
#### [Quirks](#quirks-1)
- [Editing huge files is slow](#editing-huge-files-is-slow)
- [Newline used for NUL](#newline-used-for-nul)
- [Bracketed paste (or why do I have to set 'paste' all the time?)](#bracketed-paste-or-why-do-i-have-to-set-paste-all-the-time)
@ -1046,6 +1047,31 @@ looking at some distributions:
## Quirks
#### Editing huge files is slow
The biggest issue with big files is, that Vim reads the whole file at once. This
is done due to how buffers are represented internally.
([Discussion on vim_dev@](https://groups.google.com/forum/#!topic/vim_dev/oY3i8rqYGD4/discussion))
If you only want to read, `tail hugefile | vim -` is a good workaround.
If you can live without syntax, settings and plugins for the moment:
```
$ vim -u NONE -N
```
This should make navigation quite a lot faster, especially since no expensive
regular expressions for syntax highlighting are used. You should also tell Vim
not to use swapfiles and viminfo files to avoid long delays on writing:
```
$ vim -n -u NONE -i NONE -N
```
Putting it in a nutshell, try to avoid using Vim when intending to write really
huge files. :\
#### Newline used for NUL
NUL characters (`\0`) in a file, are stored as newline (`\n`) in memory and