L'Anarcarnet - The Anarblog

Bon, xterm pue. C'est un des plus lents "émulateurs de terminaux", et ça se sent. Alors je change... J'ai longtemps utilisé rxvt pour sa faible empreinte mémoire, mais j'avais des problèmes de compatbilité. Alors je suis revenu sur xterm, mais là, il est vraiment trop poche.

J'ai bien apprécié le terminal de Gnome, mais il a trop de machins et selon moi (et d'autres), les applications ne devraient pas s'occupper de faire le "tabbing", c la job du window manager (cf. fluxbox, wmii, pwm, etc).

Je vais tenter de trouver le terminal qui bouffe le moins de mémoire en étant le plus rapide.

Je reprends donc les benchmarks de Priyadi, auquel je vais ajouter les benchs de mémoire. J'ajoute 2 chiffres, le "VSZ" et le "RSS". Définition du manpage de ps:

VSZ: virtual memory size of the process in KiB (1024-byte units). Device mappings are currently excluded; this is subject to change. (alias vsize).

RSS: resident set size, the non-swapped physical memory that a task has used (in kiloBytes).

Les résultats sont triés par utilisation du RSS.

1. xvt: 6 minutes 33 seconds, 2812 1316
2. Multi aterm: 19.8 seconds 5576 2128
3. aterm: 24.2 seconds, 5692, 2228
4. wterm: 19.6 seconds, 5916 2288
5. putty/pterm: 5508 2944
6. kterm: 6 minutes 5.6 seconds, 6952 3012
7. mrxvt: 32.3 seconds, 7952 3300
8. mlterm: 38.4 seconds, 9768 3532
9. xiterm: 7420 3568
10. xterm: 53.3 seconds, 9676 4280
11. Unicode rxvt: 25.8 seconds, 11836 5244
12. rxvt: 27.5 seconds, 11832 5296
13. Multi GNOME Terminal: 17.7 seconds, 12264 5608
14. xfce4-terminal: 19172 10172
15. GNOME Terminal : 38.4 seconds, 30636, 11756

impossibles à tester

• Eterm: 25.5 seconds, doh, pas dans testing, quelqu'un peut tester?
• Linux console (without framebuffers): 27.8 seconds (non applicable, dans le kernel)
• cxterm: 56.7 seconds (pas de package debian)
• KDE Konsole: 59.3 seconds (pas voulu installer KDE)
• hanterm: did not run (complained about missing fonts and I was too lazy to do something about it)

Observations

• certains programmes rapides consomment aussi beaucoup de mémoire. gnome-terminal et multi-gnome-terminal, par exemple, se passent du haut au bas de la liste. À l'inverse, xvt est celui qui consomme le moins de mémoire tout en étant le plus lent.
• certains terminaux "multi" (supportant plusieurs tabs) sont plus rapides et légers que leurs équivalents sans tabs, ce qui est un peu surprenant. On voit par exemple que multi-aterm consomme un tantinet moins de mémoire et est sensiblement plus rapide que aterm. multi-gnome-terminal, lui coupe tout de moitié sur son équivalent normal. Même chose pour rxvt. Je ne peux expliquer ceci (pour aterm et rxvt) seulement en théorisant que les logiciels originaux sont moins maintenus ou optimisés que leurs nouvelles versions.
• aterm et wterm, selon moi, remportent la palme des plus efficaces, quoique putty, un nouveau venu sur le monde UNIX, se taille également une place de choix en termes de consommation mémoire. Il a cependant pris 4m49.044s (user 0m9.470s, sys 0m6.811s) à faire le test, contre 1m49.248s (user 0m11.189s, sys 0m8.881s) pour aterm, sur mon thinkpad t22. En comparaison, xterm prend une éternité à rouler le test, soit 7m5.060s (user 0m6.372s, sys 0m4.058s). Dans la liste originale, j'estime donc que putty se placerait au niveau de gnome-terminal ou mrxvt, ce qui est pas mal pour un logiciel originalement conçu pour windows et pesant ... 430k! C'est donc tout de même aterm qui se méritera une place de choix dans mes priorités de "alternatives" debian.

Notes:

• je n'ai pas pris la peine de changer les fontes de tous les terminaux, trop compliqué. les résultats s'en trouvent donc probablement biaisés en faveur des logiciels n'utilisant que des fontes "fixes" (non-truetype)
• je n'ai pas testé certaines applications, ceux qui n'ont pas de chiffres n'ont pas été testées, car je n'ai pas installé le logiciel, ou parce que ça ne s'applique pas du tout
• les chiffres ont été prélevés avec ps axu | egrep rxvt\|PID, juste après le lancement du programme
• ces tests sont donc très peu formels et devraient être pris avec un grain de sel

Update: j'utilise finalement rxvt-unicode, car il est le seul des plus performants à supporter unicode, aterm et wterm échouant lamentablement...