{"partition": "head_middle", "source_domain": "blog.loof.fr", "digest": "sha1:AKGE7NZF3RSOBYJWTMBM3JVQTOBRJJQT", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2016-26/000_00018.parquet"}
new Blog( perso );
Yet another Java blog, comme on dit
Boostez votre environnement de dev
Julien Dubois a lancé le débat sur son blog en présentant ses astuces pour un build plus réactif. Entre autres idées, il utilise un disque SSD pour espace de travail. Je ne suis pas du tout convaincu par cette option, vu que ce type de disque n’est pas très tolérant aux écritures multiples. Je pense que, si les perfs peuvent être meilleures sur le coup, la durée de vie de la bête risque d’en prendre un coup. Une autre option que je suis en train d’expérimenter, suite à la même analyse venant de Julien -- l’autre Julien, celui du BreizhJug ;) Comme mon PC est sous Windows XP 32bits je ne peux pas profiter à 100% de mes deux barettes de RAM de 2Go. Windows ne voit que 3Go adressables. Même le mode “PAE” n’y a rien changé. Cependant, il existe des RamDisk comme Gavotte RAMdisk qui savent contourner ce problème et récupérer cet espace perdu. Un RamDisk de 1Go, bien assez pour mettre mon workspace. mvn clean install -Dmaven.test.skip=true sur le HD “classique” : [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 48 seconds sur le RamDisk : [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 30 seconds Reste à voir ce que ça donne sous Eclipse … Autres pistes à creuser : Tuer cette saloperie de process MacAffee Utiliser JRebel (des licences offertes au BreizhJUG !) Utiliser un disque SSD pour le repository maven (moins sujet aux écritures) Se payer un PC (voir un Mac ?) plus adapté aux devs ! Update (pour ceux qui ont la flemme de lire les commentaires) Placer le workspace en ramdisk booste un peu les perfs, mais pas autant que de placer le repository Maven ! Il faut dire que nos outils passent leur temps à charger des libs en tout genre. En plus, c’est un moyen simple pour faire du ménage dans le repo – à condition d’avoir un repo manager qui fournit les artefacts via le réseau local :) Ca pourrait être pas mal non plus de mettre l’OS en ramdisk :p Envoyer par e-mailBlogThis!Partager sur TwitterPartager sur FacebookPartager sur Pinterest
c'est quoi "pas très tolérant aux écritures multiples" ? Pour un environnement de développement "standard", 8h de travail par jour, le disque casse au bout de combien de temps ? 6 mois? 2 ans? 10 ans?Si c'est 10 ans l'option de Julien est très intéressante.
18 février 2010 à 12:10
nicolas deloof
Je ne fais que rapporter ce que j'ai pu lire sur l'utilisation des SSD. Comme boot disk pour l'OS c'est top, comme zone de travail à écriture répété ça semble déconseillé - reste à savoir dans quelle mesure, je ne suis pas spécialiste de la chose. L'option RamDisk me semble de toute manière encore meilleur en terme d'accès rapides et facile à tester.
Je pense qu'il commence à y avoir un peu de recul à ce sujet, ne serait-ce qu'avec les Macs portables haut de gamme, et que les disques SSD ont quand même l'air de bien tenir le coup en écriture (à priori un OS doit pas mal écrire lui aussi). En tout cas, pour l'instant je fais un build complet (clean package) en 9 secondes... Si mon disque lâche je ferai un article dessus!
Sinon je vais peut-être effectivement tenter le coup du RAMDisk pour comparer, surtout que je suis sous un Linux 64 bits, et que donc c'est facile à faire et peu coûteux... Si je fais le test je le mettrai sur mon blog également.
Nicolas, j'ai en fait la réponse! J'ai également un disque dur magnétique, et j'ai copié mon projet Maven dessus. Donc j'ai mon OS, Java et le repo Maven sur le SSD, mais j'ai mon projet Maven sur le disque dur physique.Résultat : les mêmes perfs que le "tout SSD", voire même mieux (j'ai eu mon record avec un build complet en 5 secondes). Ce qui compte donc ce sont les lectures du repo Maven, l'OS, Java, mais pas l'écriture, qui de toute manière doit être très limitée.Je pense que ce résultat va nous mettre d'accord, non?
Info très intéressante ... Comme quoi on ne cherche pas nécessairement du on côté. Expérience suivante : Je configure Maven pour mettre mon repo local sur le RamDisk, le workspace SVN étant sur le HD.1min 21" avec le repo sur le HD, 43s avec le repo sur le RamDisk.Ca a donc l'air d'une bonne piste !
Alexandre de Pellegrin
J'ajoute ma pierre à l'édifice. Qu'est-ce qui m'a boosté mon environnement de développement? La première chose, c'est d'avoir pris quelques soirées à apprendre par coeur les raccourcis clavier d'Eclipse. La deuxième, c'est de m'être plongé dans le développement de plugins Eclipse (cela m'a permis de comprendre la philosophie de l'IDE et de lever des points d'ombre que j'avais jusque là). OK, ok, ce n'est pas très technique tout cela mais il faut reconnaitre que la performance d'un IDE n'est pas tout le temps liée à la technique. Bon, afin de ne pas être totalement hors sujet, voilà : j'utilise JRebel. L'intégration avec WTP est très bien. Je gagne vraiment en temps. Maintenant, cela dépend beaucoup de la façon dont on travaille; si on a tendance à tester en bloc ou au fil de l'eau. D'autre part, ce qui m'a fait gagner beaucoup de temps, c'est de passer ma machine sous Linux. Sur ma machine, la différence de vitesse par rapport à XP est très frappante. Là encore, c'est très dépendant du matériel utilisé et je n'ai pas constaté le même écart sur d'autres machines. Cerise sur le gateau, je me suis ainsi rapproché de mon environnement serveur (lui aussi Linux-based). Et ça, ça aide aussi à booster son environnement de développement. Pour finir, mon collègue a un SSD dans son portable. Il fonctionne environ 10h/jour depuis 2 ans sans incident.
Nicolas De Loof
Engineer at CloudBees and Jenkins Community member
Actu Maven … suite
Actu Maven
Copyright © 2010 new Blog( perso );
| Design : Noyod.Com | Images : Cemagraphics