Laden...

Großer Build mit Visual Studio trotz SSD nicht nennenswert schneller?

Erstellt von Khalid vor 13 Jahren Letzter Beitrag vor 13 Jahren 11.756 Views
Khalid Themenstarter:in
3.511 Beiträge seit 2005
vor 13 Jahren
Großer Build mit Visual Studio trotz SSD nicht nennenswert schneller?

Moin,

wir haben hier eine Solution mit so knapp 100 Projekten drin. Da das Erstellen da schon eine weile gedauert hat, haben wir uns jetzt SSDs gegönnt. Diese natürlich gleich rein und siehe da: Hat ja mal fast nichts gebracht. Also, das System an sich geht richtig gut jetzt. Das merkt man sofort. Allerdings ist der Buildprozess vieleicht gute 10-15% schneller. Da hab ich persönlich jetzt wesentlich mehr erwartet. Es liegt alles auf der SSD. Also System, VS, Solution usw. Beim Buildprozess greift der nie auf die alte HDD zu. Das System als solches ist ein Xeon W3450 (i7 920) mit genug RAM. Das kann also auch nicht der Flaschenhals sein.

Ist das normal? Mach ich was falsch 😃?

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

Gelöschter Account
vor 13 Jahren

Build bedeutet immer sehr viel gleichzeitiger Lese und Schreibzugriff. Manche SSD´s sind in diesen Disziplinen (bei Gleichzeitigen Schreibzugriff) nicht gerade herausragend. Daher... welche habt ihr euch denn gegönnt?

Khalid Themenstarter:in
3.511 Beiträge seit 2005
vor 13 Jahren

OCZ Vertex2E. Die 3er sind ja noch nicht verfügbar (leider).

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

1.044 Beiträge seit 2008
vor 13 Jahren

Hallo JAck30lena,

aber trozdem sind SSDs um einiges schneller schneller als HDDs. Dass es 10-15% schneller ist, ist eher ein Hinweis darauf, dass es nicht an der SSD liegen kann. Also ich kann mir das zumindest schlecht vorstellen.

Hallo Khalid,

hast du mal die Geschwindigkeit getestet? Vielleicht wirst du da schlauer.

zero_x

1.457 Beiträge seit 2004
vor 13 Jahren

Hallo Khalid,

Da muss ich Jack recht geben. SSD ist nicht gleich SSD. Aber dennoch gibt es aus meiner Sicht Optimierungspotenzial bei dir. Was mir spontan einfällt ist paralleles Build. Vor allem auch mit dieser CPU. Das wird wahrscheinlich nicht 10%-15% bringen aber dennoch etwas schneller sein.

Wie es mit MSBuild / VS.NET funktioniert kannst du hier nachlesen: http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx

Khalid Themenstarter:in
3.511 Beiträge seit 2005
vor 13 Jahren

@Timur:
Danke. Ich wusste gar nicht, das MSBuild das kann. Das schau ich mir auf jeden Fall an.

@zero_x:
Wie genau sollte ich denn die Geschwindigkeit testen? Wenn ich was aus dem LAN (1gbit) auf die SSD ziehe, ist das rasend schnell. Da kommt dann keine HDD mehr mit. Wenn ich innerhalb auf der SSD Dateien verschiebe (große, oder viele viele kleine), bekomme ich das kaum mit. Die Geschwindigkeit ist also gefühlt unglaublich gut.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Khalid,

das Kompilieren des Linux-Kernels wird ja gerne als Benchmark für Multicore-Prozessoren verwendet, weil es eine Aufgabe ist, die gut mit der Zahl der Prozessoren skaliert. Das bedeutet aber, dass der Prozessor und nicht die Festplatte der Flaschenhals ist. Ich vermute, die Situation wird bei einem Großen Visual Studio Projekt nicht viel anders sein. Insofern passt eine Steigerungsrate von 10-15% durchaus ins Bild.

herbivore

Gelöschter Account
vor 13 Jahren

oha.. ok das ist natürlich eine ssd, die sich als schnell bezeichnen darf.

Als weiteren Schritt würde ich den einen oder anderen SSD-Benchmark mit ihr machen und schauen, ob auf deinem System die Werte annährend erreicht werden. Evtl ist es ja nur eine Fehlkonfiguration im bios oder sowas ähnliches.

F
10.010 Beiträge seit 2004
vor 13 Jahren

Hört sich blöd an, aber hast Du die Solution auch mal vernünftig aufgeräumt?
Wenn du ein Projekt "normal" anlegst und erweiterst, und Projekte als Verweise einfügst, und dann nicht die Pfade anpasst, wird während des Compilierens jede Assembly teilweise dann hundertfach copiert.
Wenn du aber das Ausgabeverzeichnis aller Assemblies in ein einiziges änderst,
hast du schon mal diesen ganzen Kopierwahnsinn nicht mehr.

Auch habe ich festgestellt, das der Lizenzcompiler eine heiden Zeit benötigt, da sollte man dann auch zusehen, das man nur in der Startassembly eine lic Datei hat.

Und MSBuild mit /m starten ist sicherlich bei einem rebuild die bessere Variante.

Khalid Themenstarter:in
3.511 Beiträge seit 2005
vor 13 Jahren

Die Ausgabepfade stimmen alle. Das habe ich schon zu HDD Zeiten angepasst, da es ewig gedauert hat und die Platte nur noch am rödeln war.

Das mit dem Lizenzcompiler klingt interessant. Die lics fliegen in einigen Projekten rum.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

3.825 Beiträge seit 2006
vor 13 Jahren

Ich habe meine Projekte schonmal in eine Ramdisk ausgelagert, die superschnell war.

Der Geschwindigkeitsvorteil beim Build war auch nur ungefähr 10% - 20%. Deshalb hab ichs dann gelassen.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

Khalid Themenstarter:in
3.511 Beiträge seit 2005
vor 13 Jahren

Moin,

ich hab jetzt ein MSBuild Script geschrieben, welches ein Parallel-Build auf alle Cores macht und damit ist es nochmal gut 10% schneller. Die SSD habe ich mit dem Tool "AS SSD Benchmark" getestet. Allerdings fehlen mir hier Vergleichswerte. IMHO finde ich die Schreib-/Lesegeschwindigkeit ein wenig "gering" bei 4K Blöcken. Testergebnis im Anhang.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

F
10.010 Beiträge seit 2004
vor 13 Jahren

Bei mir ist eine Samsung PB22 drin, die ist langsamer.

16.807 Beiträge seit 2008
vor 13 Jahren

Die Werte sind schon echt mager - sollten beim 4k beim 4-fachen liegen. OCZ hat aber ein eigenes Referenztool - was sagt denn das?

Welche Treiber hast Du denn verwendet? AHCI Modus aktiviert? Möglichkeit die SSD in einem anderen System zu testen? Vielleicht ist Dein Chipsatz der Flaschenhals - der kann einen sehr negativen Einfluss haben.

Gelöschter Account
vor 13 Jahren

Hier hast du ein paar referenzwerte:
http://www.testfreaks.com/blog/review/review-of-ocz-vertex-2-e-120gb-ssd/

Deine Werte sind teilweise um den Faktor 10 schlechter.... daher tippe ich mal stark auf deinen Rechner oder Settings als Fehler.

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo zusammen,

ob die konkrete SDD schnell (genug) ist oder nicht, spielt für die eigentliche Frage keine Rolle. Nach dem von BerndFfm und mir gesagten davon auszugehen, dass selbst ein Medium, das die Daten verzögerungsfrei in Nullzeit liefern könnte, den Buildprozess nicht nennenswert beschleunigen würde. Hier nochmal die entscheidenden Aussagen:

das Kompilieren des Linux-Kernels wird ja gerne als Benchmark für Multicore-Prozessoren verwendet, weil es eine Aufgabe ist, die gut mit der Zahl der Prozessoren skaliert. Das bedeutet aber, dass der Prozessor und nicht die Festplatte der Flaschenhals ist. Ich vermute, die Situation wird bei einem Großen Visual Studio Projekt nicht viel anders sein. Insofern passt eine Steigerungsrate von 10-15% durchaus ins Bild.

Ich habe meine Projekte schonmal in eine **Ramdisk ausgelagert, die superschnell war.

Der Geschwindigkeitsvorteil beim Build war auch nur ungefähr 10% - 20%.**

herbivore

16.807 Beiträge seit 2008
vor 13 Jahren

Ich denke nicht, dass wir hier einen Kernel Build mit einem Build, dessen Inhalt wir gar nicht kennen, vergleichen sollten 🤔 Nicht jeder Build bringt die CPU an ihre Grenzen. Das ist ein Vergleich zwischen Äpfeln und Birnen.
Wenn wir abstrakte Beispiele nehmen wollen, dann liefer ich NetBeans on speed als Beispiel, dessen Kompilierung sich innerhalb einer RAM Disk um den Faktor 12 verkürzen lies (Disk: 12s, RAM Disk <1s)
Ich bin der Meinung die Leistung der CPU stellt sich erst dann massiv in den Vordergrund, wenn es um parallele Build-Prozesse geht.

5.742 Beiträge seit 2007
vor 13 Jahren

Meine (60GB Modell) kommt auf folgende Werte - bei dir steht allerdings ein "BAD" in Offset/Alignment, während bei mir da ein "OK" ist. Evtl. liegt's daran.

Im übrigen scheinst du auch eine ältere Version des Benchmarktools zu verwenden.

Gelöschter Account
vor 13 Jahren

Im übrigen scheinst du auch eine ältere Version des Benchmarktools zu verwenden.

Du meinst eine neuere Version, wenn man von Major.Minor.Build.Revision ausgeht.

5.742 Beiträge seit 2007
vor 13 Jahren

Du meinst eine neuere Version, wenn man von Major.Minor.Build.Revision ausgeht.

Äh - ja. Wie soll man denn die Versionsnummer sonst interpretieren?

T
433 Beiträge seit 2006
vor 13 Jahren

Hi,

wenn man die Screenshots auch so vergleicht, sieht es ja so aus als wird bei Khalid die Platte nicht über AHCI angesprochen werden.
Was dann zumindest die schlechteren Werte erklären würde.

Gruss,
Tom

C
156 Beiträge seit 2004
vor 13 Jahren

Hallo Zusammen,
dass der Compile Vorgang mit einer SSD sich nicht wirklich radikal verkürzen lässt haben schon prominente Entwickler erfahren müssen 🙂http://www.joelonsoftware.com/items/2009/03/27.html
Für mich stellt sich die Frage ob überhaupt die Platte bei einem großen Build der Flaschenhals ist…das lässt sich aber sicher messen.
Gruß
Chaossurfer

175 Beiträge seit 2010
vor 13 Jahren

Hi,

mal eine Idee in eine ganz andere Richtung: Ist ein Virenscanner aktiv?

Unser BitDefender hat das Nervenkostüm einiger Entwickler derart stark belastet, dass wir das Teil auf den Entwicklerrechnern aubgeschaltet hatten - Ergebnis war/ist eine um knapp 40% geringere Build-Dauer.....

Bye
Michael

P.S.: Und jetzt bitte keine Antworten mit "schliess doch Dateien mit der Endung *.sonstwas aus" usw.... hatten wir alles gemacht - und trotzdem konnten wir mit dem ProcessMonitor sehen, dass der BitDefender die Finger dran hatte....

Debuggers don't remove Bugs, they only show them in Slow-Motion.

31 Beiträge seit 2010
vor 13 Jahren

Servus,
also ich hab durch MSBuild /m ca. 50 % Geschwindigkeitsvorteil bei 42 Projekten gehabt.

SDD: Curcial C300
CPU: i7 860 auf 3,6 Ghz übertaktet

Ein kleiner 'hack' wie sich MSBuild ins Studio integrieren lässt findet sich hier http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx

Wie wäre es eigentlich wenn wir hier mal einen Compile Benschmark aufstellen? In einem extra Breitrag. Wir würden alle die gleiche Solution (OpenSource?) mit möglichst vielen Projekten kompilieren und die Ergebnisse (CPU, HDD, RAM, Compilezeit) hier veröffentlichen.

Was haltet ihr von dieser Idee?

Gruß,
Thomas Sczyrba

MCPD:
Enterprise Application Developer 3.5

MCTS:
SQL SVR 2008 Developer, .NET 4, Data Access, .NET 3.5, WPF Applications, .NET 3.5, Windows Communication Foundation Applications, .NET 3.5, Windows Forms Applications, .NET 3.5, ASP.NET Applications, .NET 3.5, ADO.NET Applications

Hinweis vor 13 Jahren

Bereite alles vor und erstelle einen neuen Thread.

Bitte ab hier wieder beim Thema bleiben.

Khalid Themenstarter:in
3.511 Beiträge seit 2005
vor 13 Jahren

Hallo,

warum das ganze so lahm ist, steht jetzt fest: Das Partition Alignment ist falsch, da das System mit Hilfe eines Acronis Images wiederhergestellt wurde. Abhilfe schafft hier nur eine komplette Neuinstallation. Dazu habe ich aber momentan leider keine Zeit.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Khalid,

warum das ganze so lahm ist, steht jetzt fest

vermutlich meinst du mit "das ganze" den Build. Was du gesagt hast, erklärt aber nur, warum die Platte lahmer ist, als sie sein müsste. Aber nach dem oben gesagten würde der Build vermutlich auch dann nicht wesentlich beschleunigt, wenn die Platte schneller laufen würde. Siehe insbesondere den Ramdisk-Vergleich vom BerndFfm.

herbivore