395Fermer397
flankerLe 14/08/2017 à 14:40
Folco (./393) :
C'est très rigolo vos tests, mais je trouve ça étonnant de baser des jugements sur des cas de figure absolument inexistants...
Le jour où l'on veut faire un million de remplacement dans des données, on bosse a priori sur une bdd ou un fait un énorme refactoring de programme, mais d'une part c'est rare, d'autre part on n'y passe pas des journées entières.
Si les benchs sont plus raisonnables et suffisants pour être productifs sur des use-cases standards, je vois mal l'intérêt de tels comparatifs.

De même, comparer la mémoire utilisée me semble étonnant. Si on bosse avec un éditeur comme Visual Studio, on est à priori sur du desktop. Et dans ce cas, si on est au demi-giga de mémoire près, on a plus un problème d'outil de production que de choix logiciel.
Enfin, ce n'est que mon point de vue de non-pro, il y a sûrement des contraintes dont je ne me rends pas compte.

On ne compare pas des IDE, on compare de simples éditeurs de texte (donc aucune analyse de code). Cela dit, ça pourrait être intéressant de comparer des IDE avec l'analyse automatique (en prenant un très gros projet), mais la comparaison risque d'être délicate. Pour prendre un cas que je connais bien, Pycharm est très loin au-dessus de tous les autres en termes d'analyse de code ; ça ne serait donc pas choquant qu'il soit plus lourd ou plus lent.

Pour revenir aux éditeurs de texte :
* ça m'arrive régulièrement d'avoir de gros documents mal formatés (plusieurs dizaines de milliers de lignes) sur lesquels je dois faire des modifs avant de pouvoir les traiter. Quand tu as pas mal de changements à faire, enchaîner les modifications sans avoir 10 secondes ou sans avoir l'interface qui freeze à chaque clic change la vie oui pour choisir l'éditeur de texte qui ira dans ma boîte à outil, c'est utile de savoir qu'il peut traiter ce genre de documents (je ne veux pas avoir un éditeur de texte pour les petits documents et un autre pour les gros, sachant que j'ai déjà un IDE pour le code)
* ça permet d'accentuer des problèmes pour mieux les repérer (si ton éditeur freeze pendant 20 minutes sur 60 Mo, tu peux être sûr qu'il va avoir plein de micro-freeze sur un fichier bien plus petit)
* comme dit 0^2, c'est toujours intéressant de voir quels sont les éditeurs de texte qui sont optimisés et comment ils vont se comporter quand ils auront une grosse dizaines de documents ouverts.
Zeph (./392) :
Du coup je viens de mesurer à la louche ; je suis sur un portable pas ouf, donc mes chiffres ne sont probablement pas comparables avec les tiens :
j'ai testé sur un fixe assez classique maintenant (CPU 4 coeurs/8 threads, 32 Go de RAM, SSD). Mais comme tu dis, ça permet surtout de voir ceux qui freezent

Notepad++ : 2 secondes pour ouvrir, 134mo consommés, 31 secondes pour faire les remplacements (et un freeze pendant l'opération)
vim via cygwin : 4 secondes pour ouvrir, 76mo consommés, 15 secondes pour remplacer (+ freeze)
C'est plutôt raisonnable quand même