IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

589PARTAGES

7  0 
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
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Shepard
Membre expérimenté https://www.developpez.com
Le 04/01/2017 à 7:47
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.
8  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 04/01/2017 à 8:14
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.
8  0 
Avatar de TheGuit
Membre régulier https://www.developpez.com
Le 04/01/2017 à 10:50
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).
6  0 
Avatar de Higgins
Membre confirmé https://www.developpez.com
Le 04/01/2017 à 9:01
Citation Envoyé par grunk Voir le message
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
3  0 
Avatar de SurferIX
Membre chevronné https://www.developpez.com
Le 13/01/2017 à 14:53
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.
2  0 
Avatar de
https://www.developpez.com
Le 04/01/2017 à 9:28
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é).
1  0 
Avatar de derderder
Membre averti https://www.developpez.com
Le 04/01/2017 à 10:53
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...
3  2 
Avatar de scandinave
Membre éprouvé https://www.developpez.com
Le 04/01/2017 à 11:11
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.
3  2 
Avatar de xarkam
Membre éprouvé https://www.developpez.com
Le 04/01/2017 à 11:33
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.
1  0 
Avatar de NaSa
Membre actif https://www.developpez.com
Le 04/01/2017 à 11:36
J'ai testé les trois premiers (Sublime Text, Atom, VS) et je suis revenu sur Notepad++, pas eu besoin d'un benchmark
2  1