Discussion :

[grunt2000]

Bonsoir,

J'aimerais bien acheter un PC muni d'un SSD.
Mais je sais que ces disques aiment peu les écritures trop fréquentes. Et une compilation Java produit une centaine voire des milliers de classes dans un répertoire build pour les ré-effacer dès la compilation suivante.

Quelques mois de ce régime, et je ne sais pas si le SSD va beaucoup apprécier.

Alors, je m'étais présenté une solution ainsi:
J'achète un PC bien fourni en RAM. J'en prendrai 24 Go d'office, vu le prix que ça coûte. J'y fais un disque virtuel en Ram de 2 Go.

Et je paramètre:
Projet->sources => SSD.
Projet->classes générées => Disque Ram.
Projet->dist (*.jar, *.ear, *.war, etc.) => SSD.
Repository SVN => Disque Dur.

Je ne sais pas ce qu'il faut en penser...

Avez-vous déjà étudié des solutions au problème de la compilation sur un SSD?

En vous remerciant,

Grunt.

[tchize_]

alors:
1) la compilation java n'efface en général, pour des raisons de perfs, pas les classes qui n'ont pas subit de modification
2) je ne pense pas que tu soit doué au point de changer 1000 classes toutes les secondes 24h/jour

Donc pour moi l'activité en écriture d'un projet java n'est pas bien différente de l'activité en écriture d'un pc bureautique faisant une sauvegarde auto toutes les minutes, dans le sens ou on écrit seulement (compilation) quand on sauve.

Après, tu prend un disque dur SLC garanti 3 ans et t'es tranquille. Mes disque "classiques" meurent en général aussi dans les 3 à 4 ans donc ...


Les disque dur X25M de intel sont garantis avec une durée de vie de 5 ans à raison d'une écriture de 20G / jour dessus...

[grunt2000]

Je ne suis pas d'accord avec toi.

Si les sources bougent peu, j'en conviens, ce n'est pas le cas des fichiers .class binaires générés. Ce sont eux la source de mes tracas.

Quand je fais un ant clean dist ou un mvn clean install, et cela me prend certainement deux fois par jour, c'est bien tout le répertoire build ou target qui disparaît pour être recréé à vide.
Et la compilation réalimente tout ça.

Bien sûr, l'idéal serait d'être toujours en compilation "pure dist" où l'on ne ferait que du rafraichissement: du ant dist ou du mvn install sans clean avant. Là, effectivement, le nombre de binaires touchés serait plus faible.

Mais en pratique, le rebuild complet, il vient assez souvent. Et donc, à chaque fois, des centaines ou des milliers de fichiers .class supprimés et recréés.

[JoeChip]

Le nombre de fichiers importe peu, c'est le nombre d'écritures par "case" qui a du sens. Que tu modifies un seul fichier deux fois par jour ou 1.000.000 de fichiers deux fois par jour, bin en gros tu modifies chaque case deux fois par jour...

[tchize_]

C'est le nombre de byte écrit par jours qui compte, pas le nombre de fichiers, puisque les SSD font du balancing sur les zones mémoire afin que si c'est le même fichier qui est réécrit à chaque fois, ce soient des cases différentes impliquées et de manière à ce que toutes les zones du ssd s'usent à la même vitesse. Donc maintenant, à voir par rapport aux spec de chaque SSD lequel convient à votre travail.

Et si ça vous pose problème, mettez simplement vos projets sur un disque classique, ou investissez dans un SSD haut de gamme destinée aux entreprises. Préférez par exemple les SLC que les MLC.

[Lorantus]

Ca me plait ça:

Le nombre de fichiers importe peu, c'est le nombre d'écritures par "case" qui a du sens. Que tu modifies un seul fichier deux fois par jour ou 1.000.000 de fichiers deux fois par jour, bin en gros tu modifies chaque case deux fois par jour...

Une réflexion très pertinente.

J'ajouterai que la compilation sous Java [sous un système automatisé genre Ant qui permet de compiler uniquement que le nécessaire] ressemble à une pyramide avec en bas les fichiers .java et en haut, le .jar. La progression du bas vers le haut correspond à la probabilité que le système écrive de nouveau le fichier en cas de re-compilation. Si tu changes un fichier à la base, tout les fichiers "du dessus" faut les refaire... et des écritures en plus.

Tu obtiens, pour chaque modification d'une classe (.java) une probabilité d'écriture (génération de chaque couche de la pyramide) qui croit avec le nombre de fichier .java modifiés. Ainsi et dans un raisonnement absolu et "au pire des cas", une classe peut nécessité à régénérer 100% des couches supérieurs, et donc, à chaque re-compilation, ré-écrire l'ensemble des fichiers.

La réflexion de tchize_ est pertinente, mais je ne pouvais pas laisser passer...

1) la compilation java n'efface en général, pour des raisons de perfs, pas les classes qui n'ont pas subit de modification

Elle est pas si vrai que cela et possède de néfastes effets de bords.

[tchize_]

Elle est pas si vrai que cela et posséde de néfastes effets de bords.

mon IDE s'en sort en tout cas très bien pour déterminer quels fichier sont à recompiler. Et en général, je n'ai pas besoin de reconstituer tous les jours les couches supérieurs, dans l'environnement de l'IDE je peux très bien lancer mon code à partir des simples .class générés.
Et même dans ce cas là, je doute qu'on atteigne 20G de régénération / jour.
En environnement J2EE par contre, il est vrai qu'on régénère à chaque redéploiement le .war, mais encore une fois, je fait au maximum 10 redéploiement complet par jour, avec un gros war de 200M, on en est à 2G/jour, y a de la marge!

[grunt2000]

Le nombre de fichiers importe peu, c'est le nombre d'écritures par "case" qui a du sens. Que tu modifies un seul fichier deux fois par jour ou 1.000.000 de fichiers deux fois par jour, bin en gros tu modifies chaque case deux fois par jour...

Une case est peu ou prou l'équivalent d'un secteur dans le sens où elle ne peut être occupée que par un seul fichier à la fois.

Si je modifie un seul fichier deux fois par jour, je touche deux cases.
Si je modifie 1 000 000 de fichiers deux fois par jour en les détruisant et les re-créeant, je touche 2 000 000 de cases.

Les cases sont réparties sur le disque et gérées par un contrôleur astucieux, d'accord.
Et chaque case admet jusqu'à 100 000 cycles sur un SLC (10 000 sur un MLC, moins résistant), dixit wikipédia.

Il n'empêche: dans un cas j'ai fait +1 sur 2 cases parmi toutes celles du SSD.
Dans l'autre: +1 sur 2 000 000 de cases du SSD.
C'est quand même pas la même vitesse d'usure.

Bon, nous ne sommes pas dans notre cas réel à écrire 1 000 000 de fichiers. Mais seulement 1 000 à 3 000 dans une bonne journée de travail.

C'est quand même moins anodin que de faire de la bureautique, je trouve.

[tchize_]

d'accord, mais 1.000.000 de case, c'est 1.000.000 de fois plus de données aussi, donc au final, tout ce qui compte, c'est la quantité d'écriture (en termes de taille) que tu fais par jour. Et les disque dur sont garantis par rapport à cette quantité.

[JoeChip]

Le nombre de fichiers importe peu, c'est le nombre d'écritures par "case" qui a du sens. Que tu modifies un seul fichier deux fois par jour ou 1.000.000 de fichiers deux fois par jour, bin en gros tu modifies chaque case deux fois par jour...

A volume constant, 'videmment...................... Le nombre de fichiers n'a rien à voir...

[grunt2000]

"A volume constant, 'videmment...................... Le nombre de fichiers n'a rien à voir... "
Bien entendu. Mais justement, le problème c'est que le volume d'écritures est plus important en développement que dans une autre activité.

Mon répertoire build effacé et recréé fait 20 Mo environ.
En ce moment, je fais une petite dizaine de rebuild all par jour (problème de wsgen) parmi une trentaine de compilation dist classiques. Je suis en mise au point.
Ça me fait certainement du 200 - 300 Mo écrits par jour.
Si je ne faisais que de la bureautique, je n'en écrirais pas autant.

Si j'achete un SLC qui tient cinq ans à 20 Go par jour, ça va.
Mais si c'est un MLC à largement 10 fois moins en durée de vie et sans garantie ni mémoire supplémentaire de réserve accordée, avec 300 Mo, là, je l'entame.
Et si j'ajoute les autres activités quotidiennes sur le PC qui écrit, ça commence a faire du volume.