Un meilleur job mieux payé ?

Deviens chef de projet, développeur, ingénieur, informaticien

Mets à jour ton profil pro

ça m'intéresse

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, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Shepard Shepard - Membre confirmé 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.
Avatar de grunk 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.
Avatar de Higgins 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
Avatar de marsupial marsupial - Membre éprouvé https://www.developpez.com
le 04/01/2017 à 9:05
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 )
Avatar de romain1337 romain1337 - Membre à l'essai 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é).
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 04/01/2017 à 9:34
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.

Citation Envoyé par Shepard Voir le message
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).
Avatar de TheGuit TheGuit - Membre du Club 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).
Avatar de derderder 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...
Avatar de scandinave scandinave - Membre actif 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.
Avatar de xarkam xarkam - Membre averti 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.
Offres d'emploi IT
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil