Je veux construire un PC pour exécuter Visual Studio très rapidement. J'ai environ 30 projets C # qui incluent des services WCF, des services Web IIS. Donc pour moi, cela signifie rapidement des cycles d'édition, de compilation, d'exécution et de débogage rapides.
Comment dois-je équilibrer mon investissement dans la puissance du processeur, la mémoire et la technologie de disque, lors de la construction d'une machine à mes fins?
Réponses:
Notre équipe de développement utilise un matériel VRAIMENT rapide ... 6 000 $ + par machine de développement en janvier 2010.
La PLUS GRANDE différence qu'un composant a fait pour nous (nous avons testé une chose à la fois) était d'ajouter des E / S très rapides et de mettre tout notre code source sur ce matériel. Nous avons traversé environ 10 configurations différentes (divers RAID avec VRaptors, SSD, etc.) et le meilleur élément que nous avons trouvé était le lecteur IOXtreme de Fusion IO.
http://www.fusionio.com/products/ioxtreme/
Vous aurez besoin de beaucoup de RAM car le pilote "verrouille" la RAM en plus grande quantité, plus la taille de votre bloc formaté est petite sur le disque.
Ces mauvais garçons sont non volatils et SUPER rapides à la fois en lecture et en écriture aléatoires. Pour l'argent, nous n'avons pas pu obtenir nos plates-formes pour compiler plus rapidement.
Je vais chronométrer une compilation très rapidement pour vous donner une idée ...
OK, notre solution Master avec TOUT le code compte actuellement 37 projets, et un total de 92 281 lignes de code "exécutable" selon les résultats des métriques de code Visual Studio. Le compiler avec les paramètres du développeur DEFAULT C # dans l'EDI (juste recharger tous les paramètres pour que vous puissiez comparer objectivement avec les valeurs par défaut si vous le souhaitez) prend 22 secondes. Sur une machine identique avec 3 Velociraptors en RAID 5 prend 29 secondes, soit une augmentation d'environ 24%.
Ce test a été exécuté avec CLEAN SOLUTION suivi de REBUILD SOLUTION, donc cela aurait dû être une compilation complète.
Je ne sais pas pour vous tous, mais je compile fréquemment après de petits à moyens changements. Probablement en moyenne 80 à 100 fois par jour. Cela signifie que JUSTE le lecteur IOXtreme me fait gagner 9,3 minutes par jour. À 70 $ par heure (notre taux moyen de développement, environ), soit 10 $ par jour, par développeur. Donc, la chose prend environ 90 jours pour se payer. Pas mal vraiment ... ils sont gratuits à ce stade.
De plus, je pense vraiment que les temps de compilation ne doivent jamais dépasser le seuil de distraction d'un développeur. Faites-moi patienter 2 minutes ... sur Wiki ou Google ou Youtube en perdant du temps. C'est beaucoup plus difficile à mesurer.
OK, donc toutes les plates-formes ressemblent à ceci:
Windows 7 Professionnel 12 Go de RAM 2x Xeons quadricœurs (E5504) à 2,00 GHz. 8 GHz au total par machine. Serveur de contrôleurs RAID Highpoint 2320 Mobo (j'ai oublié le modèle, désolé) 3x Velociraptors en RAID 5, répartis en lecteurs C, D et E. Windows sur C, programmes sur D, dossiers de données utilisateur sur E. IO Xtreme Drive comme lecteur F. Tout le code (les nôtres et les DLL tierces) est sur le lecteur F.
Bonne chance à tous!
Il y a une question similaire ici: quels composants PC ont le plus grand impact sur vos temps de compilation pour Visual Studio .
Le plus gros goulot d'étranglement sera le lecteur de disque lors des générations dans Visual Studio. Depuis Visual Studio 2008, vous pouvez également profiter de plusieurs processeurs ou de plusieurs cœurs lors de vos builds. Si c'était moi, j'irais avec ce qui suit:
Lectures complémentaires:
J'utilise un ramdrive, de Dataram . Visual Studio n'utilise pas tous mes cœurs de PC (8 cœurs), j'ai donc formaté le ramdrive avec NTFS et activé la compression. Le code source a un taux de compression élevé, donc un ramdrive de 2 Go donne au moins 4 Go de stockage. Vous pouvez également activer la sauvegarde automatique de ramdrive! Cette méthode vous donne le IO le plus rapide, encore plus rapide que le SSD. Cependant, vous remarquerez que lorsque l'IO n'est pas le goulot d'étranglement, VS est très pauvre en utilisation multi-cœurs.