Discussion :

[Stéphane le calme]

Un développeur propose un test comparatif des performances de Sublime Text, Visual Studio Code et Atom,
que pensez-vous de sa méthodologie ?

Un développeur s’est proposé de lancer un test comparatif de performance des quatre éditeurs que sont Sublime Text (en version 3 beta, build 3126), Atom (en version 1.12.7), Visual Studio Code (en version 1.8.1) et TextEdit (en version 1.12 (329)). Le test a été réalisé sur un MacBook Pro 2016 embarquant un CPU Intel Core i5, tournant à une fréquence de 2.9 GHz, disposant de 8 Go de RAM LPDDR3. Sur le dispositif est installé un macOS Sierra 10.12.2. Pour les besoins du tests, tous les programmes que le développeur pouvaient voir ont été fermés.

Temps de lancement : le temps qu’il a chronométré est celui qui s’est écoulé entre le moment où il a cliqué sur les icônes des applications et celui où la première fenêtre de l’application était complètement lancée. Il a quand même précisé que, pour le cas de TextEdit, une fenêtre d’édition n’est pas ouverte mais que l’utilisateur se voit proposer une fenêtre de sélection de fichiers.

Temps d’ouverture d'une fenêtre : ici, le développeur a chronométré le temps pris par l’application entre le moment où il clique sur “ouvrir une nouvelle fenêtre” et celui où elle s’affiche entièrement. Il a noté que TextEdit a une animation de type pop-up qui se lance une fois qu’il demande l’ouverture d’une nouvelle fenêtre, ce qui le ralentit légèrement.

Temps d’ouverture des fichiers : quatre fichiers contenant 10 000, 100 000, 1 000 000 et 10 000 000 de ligne de codes ont été générés par le script Python ci-dessous. Le poids des fichiers était respectivement de 370 Ko, 3.7 Mo, 37 Mo et 370 Mo.

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
template = '''
 
#include <iostream>
 
int main() {
    return 0;
}
 
/*
%s
*/
'''
 
string = 'abcdefghijklmnopqrstuvwxyz1234567890\n'
 
with open('test-10k.cpp', 'w') as f:
    f.write(template % (string * 10000,))
 
with open('test-100k.cpp', 'w') as f:
    f.write(template % (string * 100000,))
 
with open('test-1m.cpp', 'w') as f:
    f.write(template % (string * 1000000,))
 
with open('test-10m.cpp', 'w') as f:
    f.write(template % (string * 10000000,))

Les fichiers ont chacun été testé sur les différents éditeurs en allant crescendo. Parmi les remarques qu’il a pu faire, il a indiqué que :

• Atom n’a pas pu afficher le fichier avec le million de lignes de code et a indiqué “crashed” après 40 secondes environ ;
• Visual Studio Code n’a pas permis l’ouverture du fichier avec 10 millions de lignes de code, affichant que le fichier est trop volumineux ;
• Atom n’a pas pu garder la syntaxe colorée après l’ouverture du fichier de 100 milles ligne de code ;
• Visual Studio Code ne pouvait plus garder la syntaxe colorée après l’ouverture du fichier à 10 million de lignes de code ;
• TextEdit ne dispose pas d’une fonctionnalité de coloration syntaxique ;
• TextEdit a une animation de type pop-up a l’ouverture d’un fichier, ce qui le ralentit légèrement.

En conclusion, il a retenu qu’en matière de performance, Atom et Visual Studio Code fonctionnent bien moins que Sublime Text et TextEdit : « le lancement et l'ouverture des fenêtres sont plus lentes de quelques secondes, ce qui est perceptible, et ils ont occupé beaucoup plus de RAM ».

Il note néanmoins que Visual Studio Code a un avantage sur Atom dans l’ouverture des fichiers et l’utilisation de la RAM : « il peut traiter des fichiers plus volumineux et les traiter plus rapidement qu'Atom. Lorsque j'ai testé le fichier de 3,7 Mo, il l’a ouvert en 1 seconde alors qu’Atom a pris plus de 2 secondes ».

Source :

Utilisez vous les éditeurs qu'il a comparé ? Qu'en pensez-vous ?

Que pensez-vous de sa méthodologie ? Les éléments qu'il a testé permettent-ils de tirer de telles conclusions ? Si non, quels éléments auriez vous préférez voir testés ?

[Shepard]

Je pense qu'il oublie un point important:

Si certains éditeurs mettent du temps à ouvrir un fichier, c'est sans doute parce qu'ils utilisent une structure de données adaptée à l'édition de texte (des ropes par exemple).

Ces structures optimisent l'insertion de texte en plein milieu du fichier, au prix de la création de la structure à l'ouverture. Mais notre développeur ne donne aucune chance à ces éditeurs de prouver leurs avantages.

Qui est le plus performant dans le cas d'utilisation suivant : Ouvrir un fichier de X lignes, ajouter 200 lignes après la ligne X/2, enregistrer le fichier.

[grunk]

J'en pense que :

1- Le temps de lancement n'a pas d'importance pour moi. Mon éditeur reste ouvert toute la journée ou au moins plusieurs heures , une seconde de plus ou de moins le matin ne vas pas changer ma journée
2- Si jamais j'ai un jour des fichier de 100k (voir même 10k) lignes de code à ouvrir , je vais très sérieusement envisager de changer de boite et pas forcément d'éditeur

Le seul test réellement pertinent est éventuellement celui de la RAM qui peut être important pour de petite config , mais encore faudrait il être sur que chaque éditeur propose les même fonctionnalités , parce que si je prend celui qui consomme le moins de ram mais que je dois lui rajouter 4 plugins fait avec les pieds qui triplent sa consommation c'est pas forcément terrible.

Pour finir j'utilise vscode pour faire du typescript/angular et des IDE pour tous le reste (java,c++,php). J'avais jamais acroché à sublimetext et atom , mais vscode m'a séduit.

[Higgins]

J'en pense que :

1- Le temps de lancement n'a pas d'importance pour moi. Mon éditeur reste ouvert toute la journée ou au moins plusieurs heures , une seconde de plus ou de moins le matin ne vas pas changer ma journée
2- Si jamais j'ai un jour des fichier de 100k (voir même 10k) lignes de code à ouvrir , je vais très sérieusement envisager de changer de boite et pas forcément d'éditeur

+1. Ce test ne présente pas d'interêt pour moi. Je démarre habituellement mon IDE une fois le matin, parfois 2. Le temps de démarrage m'importe assez peu.
et je m'arrange pour ne pas avoir des fichiers de code à rallonge. Sur un projet actuel (une centaine de fichier), seuls quelques-uns dépassent 5K lignes et la majorité fait moins de 3K lignes.

En revanche les lenteurs lors de l'édition peuvent être une véritable plaie et une réelle source de perte de temps

[marsupial]

Alors je ne connais aucun des 4 professionnellement ou même en amateur. Je me doute que c'est un tort. J'en reste aux vieux pots pour faire de la bonne soupe : le minimum vital nécessaire, gcc, Emacs et Geany.
Dans le même temps, mes besoins se limitent à Python, C, assembleur. Mais je découvre des outils tel SWIG qui peuvent être utiles ou piste à explorer pour améliorer.

Par contre, j'imagine un site html+PHP+bling-bling-mode-du-moment indigeste pour vscode ou atom... comme on peut en rencontrer parfois ( codé au framework et surtout non fonctionnel car optimisé pour IE )

[Invité]

J'ai stoppé la lecture par là: "Temps d’ouverture des fichiers [...]"

J'ai travaillé avec des fichiers xml et json de plusieurs GO chacun, je n'ai pas eu de problème particulier avec les multiples éditeurs. Le seul vrai problème, c'est quand ces fameux fichiers xml ou json ne contienne aucun retour chariot. Ca fait que la taille du fichier se retrouve en une seule ligne de texte dans l'éditeur, et c'est juste ingérable. De tels fichiers faisaient planter ma machine (core i7 8 coeurs, 32GO de RAM, SSD, bref une vraie machine de guerre). Même avec plusieurs milliers de lignes, tant que j'avais des retours chariot dans le texte, Ca passé partout (sans grande différence a priori, mais je n'ai pas chronométré).

[Aurelien.Regat-Barrel]

Ah ben tiens, moi qui vient d'abandonner l'utilisation (occasionnelle mais régulière) de Visual Studio Code comme alternative à Notepad++ pour sa lenteur justement.

Si certains éditeurs mettent du temps à ouvrir un fichier, c'est sans doute parce qu'ils utilisent une structure de données adaptée à l'édition de texte (des ropes par exemple).

Je ne crois pas. Sublime Text met clairement en avant le fait qu'il est optimisé : You'll love the slick user interface, extraordinary features and amazing performance.

La différence c'est que Sublime Text est codé en C++, Atom et Visual Studio Code le sont avec Electron (html/javascript/css via Nodejs).

[TheGuit]

Et puis bon ben Sublime Text n'est pas gratuit donc bon.

Un point de méthodologie qui manque toujours dans ce genre de comparatif c'est de voir la couverture fonctionnelle. Car finalement si t'as un editeur plus rapide, mais qu'il fait moins de choses c'est cool mais ça n'a pas vraiment d’intérêt de comparer du coup.

Moi tout ce que je peux en dire c'est que je trouve VSCode largement assez performant pour ce que je fais, assez souple et rapide pour l'edition rapide. Quand je veux coder dans un vrai projet avec un vrai langage je repars sur un IDE complet (autant que faire ce peut ceux de Jetbrains).

[derderder]

Ce genre de test esrlt ridicule, le temps d'ouverture peut varier car à ce moment précis l'OS scanne le réseau par exemple... Pour avoir des données correct il faudrait réaliser des milliers d'essai et en faire une moyenne... Pas tirer des conclusions sur des données non représentative...

[scandinave]

Euh le monsieur soit disant développeur, il a rajouté les plugins qui vont bien sur Atom et Sublim Text histoire d'arriver avec le même niveau de fonctionnalité que VS Code par exemple? Parce que sinon c'est comme si je comparais notepad++ et Eclipse. Dire que l'un s'ouvre plus rapidement que l'autre alors qu'il n'a aucun traitement à effectuer le langage qui est ouvert c'est facile.

[xarkam]

Dommage que pour Atom il n'indique pas le temps avant de pouvoir travailler avec.

Si la fenêtre d'Atom s'affiche vite, il en est largement moins avec la possibilité de pouvoir coder avec.
En général on a le not responding d'Atom avec la demande de waiting pour atteindre enfin l'éditeur et bosser avec.

C'est la raison pour là quel j'utilise vscode maintenant lorsque je dois éditer de petits projets.

Après franchement des fichiers à 2k de lignes en dehors de dump sql ou autres log, on en rencontre pas souvent en code.

Puis, on ne peu pas comparer vscode/atom avec sb et textedit qui eux ne fonctionne pas dans un pseudo browser (electron c'est du chromium).

Par contre j'ai vu tout au long de 2016 pas mal de personne partir sur vscode justement à cause de la lourdeur fonctionnel d'atom.

[NaSa]

J'ai testé les trois premiers (Sublime Text, Atom, VS) et je suis revenu sur Notepad++, pas eu besoin d'un benchmark

[sevyc64]

• Visual Studio Code n’a pas permis l’ouverture du fichier avec 10 millions de lignes de code, affichant que le fichier est trop volumineux ;
• Visual Studio Code ne pouvait plus garder la syntaxe colorée après l’ouverture du fichier à 10 million de lignes de code ;

Y a pas un bug, là ?
S'il ne peut pas ouvrir le fichier, il semble logique qu'il ne puisse pas en afficher la coloration syntaxique, non ?

c'est comme si je comparais notepad++ et Eclipse.

Je te confirme, notepad++ est bien plus rapide qu'Eclipse même en configuration de base

Après franchement des fichiers à 2k de lignes en dehors de dump sql ou autres log, on en rencontre pas souvent en code.

Toi, tu n'en rencontre peut-être pas souvent, mais c'est plus courant que tu pense, et qu'il ne faudrait.
C'est mon quotidien, un gros projet, il doit bien y avoir une bonne 30ène de fichiers qui dépassent les 2k de lignes de code et une bonne 10ène qui dépasse les 10k. Bon, c'est un vieux projet qui continue à évoluer et c'est en Delphi.

[air-dex]

Mouais. Ce n'est qu'un test d'éditeurs à la mode. Du coup il manque certains éditeurs qui auraient mis tout le monde d'accord. Je pense à Notepad++ et à Geany. Notepad++ est la définition même de la robustesse. Il gère même sur Linux malgré Wine. Quant à Geany il ne paye pas de mine mais il assure pour les gros fichiers, au moins sur Linux. Kate est également robuste mais il a un petit problème avec la longueur maximale des lignes, donc je l'exclus.

2- Si jamais j'ai un jour des fichier de 100k (voir même 10k) lignes de code à ouvrir , je vais très sérieusement envisager de changer de boite et pas forcément d'éditeur

Le script génère plus des fichiers textes que des fichiers de code avec des vraies lignes de code. C'est sûr qu'un fichier de code avec un tel nombre de lignes de code serait suspect quant à la qualité du code produit par l'entreprise. Par contre un fichier de log avec au moins 10.000 lignes de log est nettement plus réaliste.

[Mandotnet]

Je préfère ATOM pour son esthétisme et sa richesse mais tellement déçu par sa lenteur. Dès qu'on ajoute des modules/plugins qui agissent sur la coloration, complétion du code, c'est l'enfer.

En gratuit VSCODE me semble le plus efficace.

[Kearz]

Alors:
- Testé uniquement sous Mac. (Quid des résultats sur Windows?)
- Chronométré le temps où il clique et le temps où ça s'ouvre: via quel outil? combien de fois de suite?
- Condition des tests? (d'autres appli d'ouverte et si oui, tout le temps les mêmes?)


ça fait un peu: "Bonjour, j'ai fait des tests à l'arrach et mes conclusions sont ...".

[SurferIX]

Moi je propose de faire un compte global :
- combien de temps on économise avec des éditeurs légers au lancement x combien de fois on les lance dans la journée
- combien de temps les "gros" éditeur comme Visual Studio, ou dans mon cas, PyCharm, vous font économiser des jours de développement ou de déboguage :



Décidément.... je ne vois pas l'intérêt de comparer les choux et les carottes : ce sont deux légumes, certes, mais on ne les cuisine pas de la même façon.
Même chose pour les éditeurs de texte / IDE.

[bunam]

Le dev doit être vachement doué pour coder avec ça !!

TextEdit est capable de traiter du texte brut OK, mais il est plus souvent mis à contribution pour des fichiers à textes enrichis (rtf)

[oudjira]

Je n'est pas utiliser Visual Studio Code , ni Atom mais pour moi Sublim Text est le meilleur editeur pour l'instant en terme de rapidité et fiablité

[Golfy]

Clairement, on ne fait pas les mêmes choses avec un éditeur de texte et un IDE (ou RAD).
J'ai testé les logiciels suivants avant d'en choisir plusieurs :

• Notepad++ (7.22 Excellent pour de multiples usages. Performant mais interface ne permettant pas un thème façon "Dark Visual Studio". Nombreux plugins, lancement rapide, coloration syntaxique, FTP, comparaison de fichiers, ...)
• PSPad (Trop vieux, supporte mal l'Unicode, pas de theme sombre, très bon module FTP.)
• SynWrite / CudaText (SynWrite est très intéressant mais ne sera plus mis à jour. CudaText 1.5.4 est beau, rapide, permet l'usage de plugin, un thème sombre... mais configuration 'texte' difficile. Option multi-carets très intéressante. J'attends de voir les évolutions)
• Bracket (démarrage lourd, interface trop light)
• Atom (démarrage trop lent, quelques fonctions manquantes...)
• Sublim Text (certainement un des meilleurs... mais payant)
• RJ TextEd (11.22 - interface prometteuse mais fonction comparaison mal implémentée. Basé sur Python, pas toujours facile a comprendre... j'attends de voir les évolutions)
• ConText (comme PSPad, souffre du poids des années)
• etc...

Je sépare les suivants car ils sont installés à demeure sur mon PC pour les vrais projets :

• Eclipse (incontournable... donc à avoir sur son poste de travail)
• IntelliJ Idea community edition (beau mais... bof)
• NetBeans 8.2 (inclut JavaFX par défaut. Nécessite SceneBuilder pour créer des formes graphiques)
• Android Studio (basé sur IntelliJ. Je n'ai pas réussi à avoir un projet Android du premier coup, un comble !)
• Microsoft Visual Studio 2015 (essayez la version offline : > 1 Go)

Dans mes tests, outre la vitesse de démarrage, j'ai regardé :

• L'utilisation d'un thème sombre sur TOUTE l'interface et le texte (agréable de ne pas recevoir sa dose d'UV au bout d'une journée)
• La gestion de la coloration syntaxique (sur des pages HTML contenant du CSS et du PHP ==> XHTML)
• La possibilité de comparer deux fichiers facilement
• La possibilité d'éditer directement sur le site web (fonction FTP)
• La gestion correcte des accents/caractères spéciaux (UTF-8)
• L'accès simple à la configuration (CudaText propose un fichier JSON a éditer... *argh* )
• La gestion de l'indentation (RJ TextEd propose des lignes verticales colorées différemment sous chaque indentation, très sympa à lire) et de la remise en forme (globalement, c'est la catastrophe partout)
• La gestion de la complétion automatique (à la frappe) : ça sort un peu des caractéristiques des éditeurs de textes
• et d'autres tests

Donc, je trouve l'étude proposée ici trop réductrice.