Les performances, bonne résolution pour Atom en 2018

Nicolas Furno |

Electron est un framework qui permet de créer des apps multiplateformes à partir de technologies du web. Il a gagné en popularité ces dernières années et de nombreuses apps de premier plan l’utilisent, dont la célèbre messagerie instantanée Slack. Mais s’il est connu, ce n’est pas toujours pour de bonnes raisons : il est en effet souvent critiqué pour ses performances en deçà des apps natives ou encore sa gourmandise. À tel point que certains comparent désormais Electron à Flash… on a vu plus valorisant.

Face à ces critiques, certains reviennent au développement natif, mais d’autres espèrent améliorer les performances pour effacer la différence avec les apps natives. C’est le cas d’Atom, l’éditeur de code de GitHub qui a été le premier à utiliser Electron (le framework a, en fait, été créé pour ce logiciel). Dans un article publié sur le blog du projet il y a quelques jours, ses concepteurs ont indiqué que la performance était l’objectif principal pour 2018.

La dernière version d’Atom. Cliquer pour agrandir
La dernière version d’Atom. Cliquer pour agrandir

Plusieurs projets avaient déjà été menés en ce sens en 2017. En juin dernier par exemple, Atom avait amélioré ses performances lors de l’ouverture de gros fichiers en utilisant du code natif pour cette partie précise du logiciel. Des travaux ont aussi été menés sur d’autres fronts, notamment le temps d’attente à l’ouverture de l’app, mais ses concepteurs ont reconnu que la vitesse n’était pas la priorité auparavant.

Atom a été conçu avant tout comme un éditeur de code facile à modifier. On peut tout changer, de l’interface aux fonctions de base, et c’est indéniablement une raison importante de son succès. En contrepartie, cette souplesse a aussi contraint les développeurs à faire quelque choix qui ont eu un gros impact sur les performances. À titre d’exemple, à chaque fois que l’utilisateur tapait sur une touche du clavier, le logiciel devait faire des calculs importants, ce qui ajoutait une latence importante. Plusieurs mesures seront mis en place en 2018 pour simplifier cette partie et réduire la latence.

D’autres domaines sont encore évoqués dans l’article. Le temps au démarrage a déjà progressé l’an dernier, mais de plus gros progrès sont à attendre dans les mois qui viennent. En particulier, le logiciel ne chargera plus tous les modules dès le départ, il commencera par afficher une interface fonctionnelle, puis les chargera à l’arrière-plan.

Sorti courant 2017, Atom 1.17 avait amélioré le temps nécessaire au démarrage de l’éditeur de code. Cliquer pour agrandir
Sorti courant 2017, Atom 1.17 avait amélioré le temps nécessaire au démarrage de l’éditeur de code. Cliquer pour agrandir

L’ouverture de gros fichiers devrait aussi être plus rapide, et leur gestion ensuite poser moins de problèmes de performances. Pour cela, les créateurs d’Atom vont suivre la même stratégie, remplacer des composants sensibles aux performances par des modules développés avec du code natif à la place du JavaScript. Du C++ ou du Rust, le langage de Mozilla, pourrait être utilisé en fonction des besoins. Parmi les briques qui seront écrites en Rust, l’une d’entre elles servira à réduire la consommation de RAM du logiciel, l’un des points noirs des apps Electron.

Un logiciel aussi important qu’un éditeur de code peut-il être à la hauteur d’une app native quand il est développé avec Electron ? Peut-être pas, mais le cas d’Atom prouve qu’il y a matière à optimiser le code pour améliorer les performances et celui de Visual Studio Code, autre éditeur de code basé sur Electron, montre que l'on peut avoir de bien meilleures performances. Reste à savoir si les gains promis seront bien au rendez-vous, réponse dans les prochains mois.


avatar mrkapp | 

Pour ceux qui aime bien raler, je vous encourage à jeter un oeil à Visual Code Studio qui lui même est sous Electron. Mettez de coté 2 min le fait que le soft est un produit Microsoft, et vous verrez qu'il est très rapide sur beaucoup de point — Après on aime ou pas, c'est une affaire de gout je suppose (perso je ne l'utilise pas), mais il faut reconnaitre qu'on peut avoir des app sous Electron qui sont légères et efficaces

@Nicolas Furno, en relisant ton dernier paragraphe, je t'encourage à y jeter un oeil

avatar Nicolas Furno | 

@mrkapp

J’ai failli le mentionner parce qu’en fait, c’est mon éditeur de code de prédilection depuis quelques mois. Et en effet, il est nettement plus rapide et agréable au quotidien qu’Atom, en tout cas à mon avis.

Je recommande aussi à tous les déçus d’Atom. En ajoutant aux amateurs de Sublime Text qu’ils ont pas mal pioché d’idées de ce côté.

avatar C1rc3@0rc | 

@mrkapp

MS a fait du tres bon travail, mais il demeure qu'Electron est une ineptie.

Au moment ou suite au patchage de Meltdown on voit des pertes de performances allant a 65%, il devient indiscutable qu'un effort d'optimisation doit etre fait sur la programmation du logiciel.

Le fait d’empiler les machines virtuelles et de laisser les VM successives - jusqu'au processeur, car oui le x86 est une VM- "optimiser en memoire" les instructions a l'execution, execution qui se fait sous la conduite d'un langage de script dynamique, est absurde dans les cas ou ce meme code n'a aucun besoin d'etre dynamique, mais pourrait etre produit et optimisé une seule fois lors de la production du soft.

Le Javascript et sa VM peuvent avoir du sens... comme Java, dans certains cas, mais pas systematiquement. Le Javascript c'est un bricolage - qui s'il tend a devenir un vrai langage - a servi a dynamiser des pages Web. Ça a des applications legitimes, mais pas pour coder un editeur de texte ou autre outil qui peut etre extremement optimise et securisé lors de la compilation.

Il y a dans Atom et VCS des bonnes idees, mais les ralisation ne sont rien d'autres que des prototypes, pas des realisations serieuses.
Le prototype est necessaire pour tester des concepts et trouver la meilleure approche pour une fonction, mais apres il faut finir le boulot et pas laisser l'utilisateur se debrouiller avec un proto qui surconsomme et l'expose a toutes les failles possibles.

Faire un editeur de texte avec des techno Web, c'est juste absurde.

avatar mrkapp | 

haha :-) tu dois pas être un dev toi :-) — hahaha, merci tu m'as bien fait rigoler :)

avatar Amaczing | 

@mrkapp

@C1rc3@0rc est un troll

Bon à savoir

avatar mrkapp | 

#dontfeedthetroll c'est noté

avatar mrkapp | 

Alors pourquoi avoir terminé l'article comme ça:

"Un logiciel aussi important qu’un éditeur de code peut-il être à la hauteur d’une app native quand il est développé avec Electron ? Peut-être pas..." — je pense que VS Code devrait être mentionné dans cet article

avatar Nicolas Furno | 

@mrkapp

Parce qu’on reste loin des performances d’un Textmate ou BBEdit, par exemple. C’est toujours un compromis.

Mais je vais mentionner VSCode, c’est une bonne idée.

avatar mrkapp | 

merci  — me voilà en train de défendre un logiciel de Microsoft que je n'utilise pas — ?

avatar bompi | 

Visual Code est assez réussi en effet.
Atom est évidemment très capable, avec de nombreuses fonctionnalités et une certaine plasticité, mais ce n'est pas ce dont j'ai besoin.

In fine Sublime Text est mon éditeur de prédilection car il a toutes les fonctions que je souhaite, il est très rapide, se lance rapidement et ne mange pas des GB de RAM inutilement.
Sur Mac, je prends parfois Text Mate et TextWrangler. Et pour LaTeX, TeXMaker, qui n'est pas génial mais me suffit.

avatar mrkapp | 

On a tous nos éditeurs de prédilection — Je voulais juste signaler que tous les soft écrits sous Electron ne sont pas des monstres qui avale des Go de RAM juste pour se lancer.

je suis, pour ma part, très content des IDE proposé par JetBrain (webStorm, phpStorm et DataGrid) — qui sont lourds, qui ont des inconvénients mais qui, pour ma part, en font beaucoup plus que les autres (Sublims, Atom, ou les plus anciens). Car pour ma part je n'ai pas besoin d'un éditeur de text, mais bien d'un IDE — c'est pour ça que j'ai quitté Coda il y a des année

mais c'est un autre débats :-) — #gg pour Microsoft sur ce coup, espérons que VSCode reste aussi léger en grandissant

avatar C1rc3@0rc | 

@mrkapp

Il faut aussi comparer ce qui est comparable: SublimeText c'est un editeur de texte, pas un IDE.
Apres, il faut qu'un IDE embarque un bon editeur de texte et cela peut se faire de maniere integrée ou collaborative.

Pour ma part j'aime beaucoup l'ancien principe d'Apple qui favorise l'outil le plus simple possible et optimisé, quitte a multiplier les outils, plutot que les mammouths graisseux qui veulent tout faire et au final ne font rien de bien.
Pour moi la definition de l'horreur c'est Word, le pire soft au monde: bon a rien, mauvais a tout et un gouffre temporel. Xcode dans son genre est pas mal non plus, mais on a pas trop le choix sur Mac.

Dans mon cas, j'adore Vim comme editeur de code, mais je vais pas lui demander de faire autre chose, et j'utilise aussi des pures merveilles comme Scrivener/Omnigraffle/Freeplane(moche au possible, buggue, mais j'ai pas encore trouve mieux dans le genre)/ Excel... quand il s'agit de faire une travail de conception...
A chaque tache son outil... Certes ça demande de prendre du temps pour choisir l'outil et pour apprendre a le maitriser mais une fois cela fait, on est productif et on passe pas son temps a chercher quelle fonction planquée dans je ne sais quel recoin tordu pourrait faire la tache necessaire...

avatar buluhab | 

Perso j'utilise Atom mais uniquement pour Markdown et afficher du code en formation

Pour le reste c'est jEdit, très personnalisable aussi et multi-plateforme

Et beaucoup (beaucoup) plus rapide pour les gros fichiers bien qu'écrit en Java

avatar MaksOuw | 

De mon côté, je considère pas qu'un fichier XML de 15Mo est un "gros fichier", et pourtant, Atom est pas foutu de l'ouvrir chez moi (pourtant, core i5 + 16Go ddr4, le PC à pas un an encore).

Obligé de retourner sur Sublime Text pour les gros fichiers, le reste c'est Atom. J'attends vraiment qu'ils optimisent l'ouverture de ces derniers, parce que c'est vraiment handicapant de devoir installer un second éditeur plus performant pour une tâche courante...

avatar mrkapp | 

Atom a une limitation volontaire pour les fichiers > 2 Mo de mémoire (sans mauvais jeu de mot)... c'est une restriction volontaire qui cache un pb pour gérer des gros fichiers... mais on a peu souvent (jamais?) de gros fichier de "code" qu'on édite à la main
le jour ou t'as un fichiers source de 15 Mo, il sera temps de te demande si t'aurais pas mieux fait de refactoriser avant :-) — je suppose que dans certain cas très spécifique, on en a besoin, alors il faut juste se rendre à l'évidence: Atom n'est pas fait pour ces cas là...

avatar KeepAlive | 

La nouvelle version 8 de Skype sortie en novembre est très gourmande en ressources, je me demande si Microsoft l'a aussi écrite avec Electron, qu'en pensez-vous?

avatar jeanpaulpollue | 

C'est certain, si tu presses cmd shift et + ou - , tu verras l'interface s'agrandir ou rétrécir comme dans une vue navigateur.

CONNEXION UTILISATEUR