Pourquoi Vim ne peut-il pas ouvrir un fichier texte de 100 Mo alors que je dispose de 16 Go de RAM?

67

J'ai un fichier de sauvegarde de base de données MySQL de 100 Mo et j'ai du mal à l'ouvrir dans Vim sur ma machine Linux qui dispose de 16 Go de RAM.

Vim se bloque (au moins inutilisable). C'est quelque chose que je ne comprends pas. J'ai 16 Go de RAM, pourquoi ne puis-je pas charger un fichier de 100 Mo dans un éditeur?

Est-ce à cause de Vim? Je pensais que toute la gestion de la mémoire est gérée par le système d'exploitation.

vim memory

— Demander et apprendre
source

3

Envisagez d'utiliser un éditeur HEX au lieu d'un éditeur de texte pour afficher de tels fichiers. Un exemple d'éditeur hexadécimal avec une interface de type vi serait hexer.

— Ruslan

13

N'oubliez pas que la mémoire vive n'est pas ce que nous manquons lorsque nous manquons de mémoire depuis des décennies. La mémoire est maintenant virtualisée. il est divisé en pages et ces pages peuvent être échangées sur le disque. La quantité de mémoire allouée à partir de l'espace d'adressage d'un processus et la quantité de RAM consommée ont très peu à voir l'une avec l'autre. Lorsque vous manquez de mémoire, vous manquez d' espace d'adressage , pas de RAM . La meilleure façon de penser à cela est la mémoire est l'espace disque , chaque processus obtient une certaine quantité fixe de cet espace, et la RAM est un matériel qui rend votre disque plus rapide .

— Eric Lippert

21

@EricLippert Sauf que les disques traditionnels sont si lents (comparés à la RAM) qu'ils ne conviennent que pour stocker les pages de mémoire virtuelle qui ne sont pas utilisées. Si un processus se bloque (ou est au moins inutilisable, comme l’a dit le PO) en raison de la substitution d’échange, c’est précisément parce que la RAM est ce qui lui manque.

— Envoyé le

6

@EricLippert ne dispose plus d'espace d'adressage que sur les systèmes 32 bits actuels. Je doute que l'utilisateur disposant de 16 Go de RAM utilise encore le noyau PAE 32 bits au lieu du noyau 64 bits normal.

— Ruslan

3

@depquid: C'est un bon point. Le commentaire de mon commentaire est que le PO semble croire que "j'ai chargé 100 Mo de matériel, j'ai 16 000 Mo de RAM, donc 100 Mo de mes 16 000 Mo de RAM ont été consommés". Ce système de croyance est obsolète.

— Eric Lippert

69

Vim a parfois des problèmes avec les fichiers comportant des lignes particulièrement longues. C'est un éditeur de texte, il est donc conçu pour les fichiers texte, avec des lignes d'une longueur maximale de quelques centaines de caractères.

Un fichier de base de données peut ne pas contenir beaucoup de caractères de nouvelle ligne, il pourrait donc s'agir d'une seule ligne longue de 100 Mo. Vim ne sera pas satisfait de cela, et bien que cela fonctionne probablement, le chargement du fichier risque de prendre un certain temps.

J'ai certainement ouvert des fichiers texte beaucoup plus gros que 100 Mo avec Vim. Le fichier n'a même pas besoin de tenir dans la mémoire en une fois (puisque Vim peut échanger les modifications sur le disque si nécessaire).

— Greg Hewgill
source

1

J'ai aussi remarqué les très longues lignes, essayées avec un autre fichier sans très longues lignes, voir une grande amélioration. Merci

— Demandez et apprenez

11

@AskandLearn Selon le type de fichier, les performances peuvent augmenter si vous set synmaxcol=120(ou un autre numéro approprié). J'ai remarqué des progrès énormes dans le passé.

— sapi

Est-ce que quelqu'un sait si la récente fourche Neovim gérera mieux les longues lignes? Je suppose que ce n'est pas un problème particulièrement commun ...

— Hemmer

@GregHewgill c'est vrai, j'ai aussi observé cela, mais comment le saviez-vous?

— Rahul Patil

56

D'après mon expérience, Vim n'étouffe pas les fichiers volumineux , mais les longues lignes . Utilisez cette commande pour mysqldumputiliser des lignes plus courtes au détriment d'un fichier plus volumineux :

$ mysqldump --complete-insert -u -p

De plus, vous pouvez ouvrir Vim et lui demander de ne pas analyser votre .vimrcfichier ou de charger des plugins avec cette commande:

$ vim -u NONE output.sql

Le chargement de Vim de cette manière utilisera moins de mémoire et ne nécessitera pas que Vim analyse le fichier entier comme le font de nombreux plugins.

— dotancohen
source

15

"chargez VIM sans .vimrc et plugins (VIM propre), par exemple pour des fichiers énormes

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

— zzapper
source

13

Essayez d'utiliser lessau lieu de vimsi vous voulez voir un fichier volumineux directement. Vim essaie de faire beaucoup de choses différentes lors de son premier chargement - en analysant le fichier (éventuellement en plusieurs passes) pour essayer de déterminer la syntaxe à utiliser, en mettant en évidence la syntaxe et en recherchant des modèles en haut et en bas du fichier. Ensuite, lorsque vous éditez le fichier, vim enregistre les fichiers swap et conserve les arborescences défaites (l'historique des annulations dans vim est une branche, pas linéaire comme dans tout (?) Autre éditeur), et réévalue constamment la coloration syntaxique lorsque le texte change, etc.

Rien de tout cela ne justifie nécessairement pourquoi il doit être si inutilisable avec des fichiers géants, mais c'est plutôt une explication de certaines des raisons pour lesquelles c'est.

— godlygeek
source

Voir ma réponse pour savoir comment empêcher VIM d'effectuer des opérations lourdes telles que l'analyse de fichiers.

— dotancohen

Oui, la mise en évidence de la syntaxe sur des éléments tels que XML et SQL peut être très lente pour les fichiers plus volumineux.

— Marcin

9

Vim ne charge pas simplement le fichier tel quel dans la mémoire. Il le convertit en structures internes (lignes, mots, etc.), met en évidence la syntaxe à l'aide d'un langage de script interne, etc. tout cela consomme de la mémoire (beaucoup plus qu'un octet pour un caractère) et du temps CPU.

— demonkoryu
source

Consommer de la mémoire n'est même pas le problème. Le temps de calcul utilisé (et un gel visible pendant que vous attendez), est.

— Courses de légèreté avec Monica

Ce temps CPU est principalement utilisé par le script de coloration syntaxique.

— demonkoryu

Oui je suis d'accord. Je dis simplement qu'il est très peu probable que l'utilisation de la mémoire (a) soit un problème ou (b) cause un long délai, contrairement à ce que dit votre réponse.

— Courses de légèreté avec Monica

Vous avez raison, j'ai mis à jour ma réponse en conséquence.

— demonkoryu

7

Vous pouvez essayer de le charger en tant que binaire. J'ai eu de la chance avec ça pour de très gros fichiers non-textuels

vim -b HUGEFILE

Il est également possible que l'IIRC utilise vim comme éditeur hexadécimal, voir: http://usevim.com/2012/06/20/vim-binary-files/

— Steve Butler
source

4

J'espère que votre problème est davantage lié au besoin des fichiers VIM (tels que les fichiers d'échange) que de la RAM.

Dans de nombreux cas, les fichiers temporaires créés par VIM se trouvent dans le même répertoire que le fichier que vous ouvrez. Si tel est le cas pour vous, vous pouvez alors vérifier en vérifiant l'espace disque disponible dans le répertoire en cours.

Heureusement, il existe une bonne documentation sur la manière de spécifier un emplacement différent pour les fichiers d'indexation / swap de VIM:

Vous pouvez également désactiver le fichier d'échange

Désactivation de la création de fichiers d'échange dans vim

— samt
source

1

J'ouvre parfois de grandes sauvegardes de bases de données au format texte .sql. Les fichiers très volumineux, ou les fichiers avec de très longues lignes, semblent souvent mettre longtemps à s'ouvrir dans vim. Cela pourrait être lié au traitement de la syntaxe et à la mise en surbrillance des couleurs, comme mentionné dans les réponses de @zzapper et @demonkoryu.

Une solution rapide pourrait consister à appuyer sur "control-G" pendant le chargement du fichier pour annuler la pré-traitement mettant en surbrillance la syntaxe.

— digitalsean
source