Emacs sur Windows 7 très lent lorsque l'ordinateur est en dehors du réseau de l'entreprise

J'utilise GNU Emacs 24.3 sur Windows 7 et normalement je n'ai aucun problème de vitesse / réactivité.

Je lance Emacs avec runemacs.exe

Cependant, lorsque je voyage et que j'essaie de me connecter au réseau de mon entreprise via VPN (ou simplement de travailler hors ligne sans connexion au réseau de l'entreprise), Emacs devient souvent incroyablement lent - cela peut prendre plusieurs minutes pour ouvrir un tampon et cela ne fonctionne tout simplement pas répondre aux commandes du clavier.

(Je suis toujours très intéressé par une solution) Tous les fichiers de texte et de configuration pertinents sont enregistrés dans mon répertoire utilisateur C:\Users\myusername.domainname\Documentssitué sur le disque dur local (il ne devrait donc pas avoir besoin d'accéder à des serveurs distants), mais je me demande si Windows 7 pourrait essayer de synchroniser ces fichiers avec un serveur

J'utilise également la fonction "fichiers hors ligne" pour d'autres répertoires et je me demande si cela pourrait avoir un effet sur mon problème.

Le problème se produit non seulement lorsque le VPN est utilisé, mais également lorsque l'ordinateur est simplement hors ligne et non connecté au réseau de l'entreprise.

microsoft-windows performance networking

— La plupart du temps inoffensifs
source

Étant donné que "Le problème se produit non seulement lorsque le VPN est utilisé, mais également lorsque l'ordinateur est simplement hors ligne et non connecté au réseau de l'entreprise", il n'est pas clair que le VPN ait quelque chose à voir avec le problème.

— Joe Corneli

Que diriez-vous d'utiliser la version publique la plus récente d'Emacs au lieu de 24.3? Y a-t-il une raison d'essayer de dépanner une ancienne version d'Emacs lorsqu'une nouvelle version stable est facilement disponible?

— lawlist

@lawlist: merci, je pense que j'utilise actuellement Emacs 24.5, je vérifierai cela demain quand je serai de retour à l'ordinateur. Quoi qu'il en soit, ne devrait-il pas être possible dans toutes les versions stables d'Emacs de fonctionner sans problème dans n'importe quel environnement réseau?

— MostlyHarmless

Pourquoi Emacs ferait-il des requêtes DNS? Pourquoi la lenteur serait-elle due à des requêtes DNS plutôt qu'à un autre type d'accès au réseau?

— Gilles 'SO- arrête d'être méchant'

lists.gnu.org/archive/html/bug-gnu-emacs/2012-10/msg00230.html offre quelques conseils et (setq w32-get-true-file-attributes nil)pourrait vous aider.

— Luís Oliveira

Réponses:

La raison de ce problème peut être l'utilisation du recentfmode. Vous devez désactiver le nettoyage des fichiers indisponibles à l'aide de la commande suivante dans votre ~ / .emacs (ou ~ / .emacs.d / init.el si vous l'utilisez):

(setq recentf-auto-cleanup 'never)

— circulation cérébrale
source

merci beaucoup - cela semble prometteur, mais je n'utilise pas le recentfmode et je n'ai pas trouvé une telle option dans mon .emacs ou init.el

— MostlyHarmless

J'ai le même problème que OP, et cela n'a rien fait pour m'aider.

— PaulB

Je ne peux penser à aucune raison que ce soit récente qui aurait un impact. Il s'agit simplement d'une liste de fichiers récents. Ils ne sont ni restaurés ni vérifiés,

— RichieHH

Un fichier recentf très volumineux peut en effet introduire une latence intermittente, mais cela ne semble pas être le problème tel que décrit par OP.

— InHarmsWay

J'ai eu le même problème, et il semble que cela soit dû au service Windows Netlogon . La solution la plus simple consiste à le désactiver en dehors du réseau de votre entreprise, en exécutant la commande suivante dans la ligne de commande:

net stop netlogon

Lorsque vous êtes de retour sur le réseau de l'entreprise, redémarrez-le à l'aide de

net start netlogon

— arvidj
source

Un certain nombre de raisons possibles, deux du haut de ma tête (eu ces problèmes dans le passé.)

Vous pouvez avoir un dossier distant mappé dans Windows, et lorsque vous êtes hors du réseau local, cela peut vous ralentir beaucoup (descendre du VPN n'aide pas vraiment, en fait cela peut aggraver les choses car Windows continuera d'essayer de l'atteindre arrêté uniquement par des délais d'attente.) Les versions plus récentes de Windows semblent y faire face un peu mieux, mais quand même. Essayez d'exécuter net use * /deletedans une invite de commande et voyez si cela aide.
Vérifiez si vous utilisez tramp(j'en doute car vous êtes sous Windows, mais j'utilise aussi Windows avec Linux et j'utilise trampdonc ce n'est pas totalement hors de question.) Si c'est le cas, essayez de courir tramp-cleanup-all-connectionslorsque vous êtes hors du réseau.

Si tout cela ou autre chose que les gens suggèrent ici ne vous aide pas, vous devrez peut-être effectuer un dépannage plus approfondi. Le meilleur outil que j'ai trouvé est le Moniteur de processus de Sysinternals ( https://technet.microsoft.com/en-us/sysinternals/bb896645 ). C'est une bête complexe à gérer, et elle nécessite au moins une compréhension de base du système d'exploitation Windows, mais elle est capable de supprimer totalement les conjectures du processus et de réduire à zéro le délinquant.

— Yuri Steinschreiber
source