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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    6 367
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 6 367
    Points : 154 833
    Points
    154 833
    Par défaut Un développeur propose un test comparatif des performances de Sublime Text, Visual Studio Code et Atom
    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    359
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 359
    Points : 1 247
    Points
    1 247
    Par défaut
    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.

  3. #3
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    6 385
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 385
    Points : 18 560
    Points
    18 560
    Par défaut
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  4. #4
    Membre confirmé
    Avatar de Higgins
    Inscrit en
    juillet 2002
    Messages
    469
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 469
    Points : 500
    Points
    500
    Par défaut
    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
    7 fois à terre, 8 fois debout

  5. #5
    Expert confirmé Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2014
    Messages
    1 315
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2014
    Messages : 1 315
    Points : 5 007
    Points
    5 007
    Par défaut
    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 )
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  6. #6
    Invité
    Invité(e)
    Par défaut
    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é).

  7. #7
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    juin 2003
    Messages
    5 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 732
    Points : 10 549
    Points
    10 549
    Billets dans le blog
    3
    Par défaut
    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).

  8. #8
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2005
    Messages
    27
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 27
    Points : 90
    Points
    90
    Par défaut
    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).

  9. #9
    Membre averti
    Homme Profil pro
    Lycéen
    Inscrit en
    décembre 2014
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Lycéen

    Informations forums :
    Inscription : décembre 2014
    Messages : 106
    Points : 322
    Points
    322
    Par défaut
    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...

  10. #10
    Membre éprouvé Avatar de scandinave
    Homme Profil pro
    Développeur Java, NodeJs/Angular
    Inscrit en
    mai 2009
    Messages
    277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Java, NodeJs/Angular

    Informations forums :
    Inscription : mai 2009
    Messages : 277
    Points : 912
    Points
    912
    Par défaut
    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.

  11. #11
    Membre éprouvé
    Profil pro
    Développeur .NET
    Inscrit en
    février 2005
    Messages
    354
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2005
    Messages : 354
    Points : 953
    Points
    953
    Par défaut
    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.

  12. #12
    Membre actif
    Profil pro
    Developpeur
    Inscrit en
    décembre 2004
    Messages
    60
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : décembre 2004
    Messages : 60
    Points : 203
    Points
    203
    Par défaut
    J'ai testé les trois premiers (Sublime Text, Atom, VS) et je suis revenu sur Notepad++, pas eu besoin d'un benchmark

  13. #13
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 926
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 926
    Points : 26 898
    Points
    26 898
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    • 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 ?

    Citation Envoyé par scandinave Voir le message
    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

    Citation Envoyé par xarkam Voir le message
    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.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  14. #14
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 621
    Points : 3 644
    Points
    3 644
    Par défaut
    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.

    Citation Envoyé par grunk Voir le message
    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.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  15. #15
    Membre régulier
    Profil pro
    Inscrit en
    mars 2005
    Messages
    129
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 129
    Points : 88
    Points
    88
    Par défaut
    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.

  16. #16
    Membre expert Avatar de Kearz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2012
    Messages
    856
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2012
    Messages : 856
    Points : 3 682
    Points
    3 682
    Par défaut
    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 ...".

  17. #17
    Membre chevronné

    Homme Profil pro
    Mentaliste
    Inscrit en
    mars 2008
    Messages
    872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Mentaliste
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 872
    Points : 1 771
    Points
    1 771
    Par défaut
    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 :

    Nom : ajeter.jpg
Affichages : 6109
Taille : 27,8 Ko

    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.
    .I..

  18. #18
    Membre du Club
    Profil pro
    Inscrit en
    mars 2006
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 38
    Points : 55
    Points
    55
    Par défaut TextEdit !!!
    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)

  19. #19
    Membre régulier
    Homme Profil pro
    consultant informatique freelance
    Inscrit en
    janvier 2016
    Messages
    73
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Tchad

    Informations professionnelles :
    Activité : consultant informatique freelance
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : janvier 2016
    Messages : 73
    Points : 70
    Points
    70
    Par défaut Alors là c'est interressant
    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é

  20. #20
    Membre du Club
    Homme Profil pro
    Inscrit en
    octobre 2013
    Messages
    41
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2013
    Messages : 41
    Points : 64
    Points
    64
    Par défaut
    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.

Discussions similaires

  1. Réponses: 2
    Dernier message: 29/06/2011, 11h47
  2. Réponses: 7
    Dernier message: 01/09/2010, 13h25
  3. [outils-test] Comparatif des Outils de test
    Par geforce dans le forum Test
    Réponses: 1
    Dernier message: 15/03/2010, 21h02
  4. Réponses: 3
    Dernier message: 08/08/2007, 09h29
  5. [SGBDR][XML] Quel est le comparatif des performances ?
    Par kritopal dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 28/11/2005, 11h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo