Ich habe hier ein groesseres VS2017/Windows/C++ Solution ~500LOC, ca. 60 Projekte in der Solution (externe Libs: Qt, Boost, etc.) - ich bin Freelancer und betreue die Analyse Für die Kompilezeit-Analyse werden die Buildzeiten (Frontend/Backend) für die ganze Solution, der Projekte und die der einzelnen Cpp-Dateien erfasst und daraus mit GnuPlot ein paar nette kumulative Charts gezaubert, das ganze basiert auf MSBuild und einem Parser für die Logausgabe vom CL Für eine gute Analysegrundlage haben wir diese Charts für die letzten 5 Haupt-Releases (alle paar Monate) erstellen lassen - für die weitere Analyse läuft jetzt ein Script auf dem Build-Server das diese Charts wöchentlich mit den Veränderungen erweitert Bei der Analyse der Daten ist augefallen das der Wechsel von VS2015 auf VS2017 mitte letzten Jahres ca. 30min mehr Buildzeit verursacht hat - es ist nur dieser Wechsel in der Source-Controlle zu erkennen d.h. ein paar vcproj Datei und die Sln wurden veraendert - sonst kein größeren Änderungen Im Internet bin ich auch auf ein paar Post gestossen die dieses Problem umschreiben - die Lösungen die dort genannt werden haben in diesem Projekt aber keine Wirkung: https://developercommunity.visualstudio.com/content/problem/37643/vs-2017-build-very-slow.html Hat hier jemand ähnliche Erfahrungen gemacht? Zusatz-Infos: -Ja ich weiss das Windows und das VStudio ganz ganz schlecht sind und mit dem GCC und Linux sowas nicht passiert wäre, leider kann ich die Vorgaben nicht ändern :)
-VS2017 ist die aktuelle Version und es scheint so als ob einfach alle Kompilierzeiten der Cpps länger geworden sind -die Build-Zeiten werden automatisch mit einem Script aus der Versions-Kontrolle erstellt, d.h. entsprehchenden Release ziehen, alles Bauen, Logs Analysiere, Reports erzeugen -die Builds laufen ungestört auf einem 32 Thread Build-Server mitten in der Nacht ohne andere aktiven User -auch auf den lokalen Entwicklungs-Systemen sieht man mit MSBuild oder in der IDE die Unterschiede zwischen VS2015 und VS2017 deutlich -Wenn man mit 5 Threads kompiliert sind es ca. 30min, bei einem 1 Thread Build - sind wir locker bei 2h Ich bin gespannt wie die Zusatz-Analyse mit VS2019 ausfällt
Rolf M. schrieb: > cppbert schrieb: >> ~500LOC > > Klingt für mich jetzt nicht so arg groß ;) 500(K)LOC !!!!
cppbert schrieb: > 32 Thread Build-Server Das auch nicht ;) Das Geld für den Freelancer in einen Buildserver stecken, der den Namen verdient, Problem gelöst. Oliver
hier noch die Links die ich gefunden habe: https://developercommunity.visualstudio.com/content/problem/429226/c-builds-slow-cppcompiler-in-vs-2017-1594.html https://stackoverflow.com/questions/48905344/very-slow-vs2017-c-linker-speed
Rolf M. schrieb: > Klingt für mich jetzt nicht so arg groß ;) cppbert schrieb: > 32 Thread Build-Server Das auch nicht ;) Das Geld für den Freelancer in einen Buildserver stecken, der den Namen verdient, Problem gelöst. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > cppbert schrieb: >> 32 Thread Build-Server > > Das auch nicht ;) > > Das Geld für den Freelancer in einen Buildserver stecken, der den Namen > verdient, Problem gelöst. > > Oliver die haben auch einen Dual CPU Server mit 128 Kernen für >30k und Incredibuild mit 20 Agents Es ist aber das Ziel meines Projektes die Grundzeiten runter zu bringen weil die Entwicklung trotzdem darunter leidet wenn hier und da ein paar Minuten zu langen gebaut wird - das summiert sich alles sehr schnell wenn da 20 oder mehr Entwickler dran sind
cppbert schrieb: >> Das Geld für den Freelancer in einen Buildserver stecken, der den Namen >> verdient, Problem gelöst. Kurz: Die Entwicklungsleitung möchte die Ursache für die Buildzeiten finden und nicht mehr weiter mit Hardware das Problem unterdrücken - das mit VS2015 und VS2017 ist ein erster Fund und ja die Entwickler haben alle leistungsstarke und aktuelle Entwicklungsrechner
Ja und, sollen wir jetzt deine Arbeit machen, weil du zu faul bist Tracing Tools anzuwerfen, um nachzuschauen wo die Zeit verplempert wird? Aber Tipp am Rande: Nimm den VS 6.0 cl, der ist 10x schneller, als der VS2015.
cppbert schrieb: > Kurz: Die Entwicklungsleitung möchte die Ursache für die Buildzeiten > finden und nicht mehr weiter mit Hardware das Problem unterdrücken - das > mit VS2015 und VS2017 ist ein erster Fund Auch kurz: Die Entwicklungsleitung möchte also das Problem gelöst haben, aber die Ursache des Problems →VS2017← nicht loswerden. Äh, ja... Lösung: Die sollen sich dran gewöhnen, es ist jetzt einfach so. Daran lässt sich nichts ändern. Die eigene Software kontinuierlich verschlechtern ist seit einiger Zeit die neue Firmenphilosophie von Microsoft. Kannst du bei jedem Patchday und bei jedem MS-Produkt sehen. Die Leute machen sich aber abhängig von MS-Software und Microsoft weiß das, deswegen ändert sich da auch nichts.
Udo K. schrieb: > Ja und, sollen wir jetzt deine Arbeit machen, weil du zu faul > bist Tracing Tools anzuwerfen, um nachzuschauen wo die Zeit > verplempert wird? > > Aber Tipp am Rande: Nimm den VS 6.0 cl, der ist 10x schneller, > als der VS2015. meine Frage war einfach und freundlich:
1 | Hat hier jemand ähnliche Erfahrungen gemacht? |
oder darf man auch nicht nach Erfahrungen fragen?
T.roll schrieb: > Die Entwicklungsleitung möchte also das Problem gelöst haben, aber die > Ursache des Problems →VS2017← nicht loswerden. Äh, ja... unter Linux/GCC/Clang baut die Software auch nicht super schnell und zusätzlich ist es eben leider nicht das Kunden-System also was hilft dein Statement?
Udo K. schrieb: > Ja und, sollen wir jetzt deine Arbeit machen, weil du zu faul > bist Tracing Tools anzuwerfen, um nachzuschauen wo die Zeit > verplempert wird? Welches Tracing Tool könnte ich denn verwenden um das Problem besser ein zu grenzen? Mein Kompiletime-Tracing sagt mir ja das alle cpps langsamer bauen - die Frage ist gibt es Optionen mit denen man das Verhalten beeinflussen kann oder Tipps usw. - mehr als "ist eben alles Scheisse von Microsoft" - das weiss ich schon
cppbert schrieb: > Udo K. schrieb: >> Ja und, sollen wir jetzt deine Arbeit machen, weil du zu faul >> bist Tracing Tools anzuwerfen, um nachzuschauen wo die Zeit >> verplempert wird? > > Welches Tracing Tool könnte ich denn verwenden um das Problem besser ein > zu grenzen? > > Mein Kompiletime-Tracing sagt mir ja das alle cpps langsamer bauen - die > Frage ist gibt es Optionen mit denen man das Verhalten beeinflussen kann > oder Tipps usw. - mehr als "ist eben alles Scheisse von Microsoft" - das > weiss ich schon Du musst halt schauen, wo die Zeit genau draufgeht. Compiliere mal mit -Bt, da siehst du die Zeiten im Log. Wenn das nicht ausreicht, schau dir den ProcessMonitor an. Es gibt auch Tools, die noch mehr können. Da wird im Detail aufgelistet, was ein Program macht, und wie lange es dauert. Schau mal, ob vorkompilierte Header verwendet werden, und ob die eventuel eingeschaltete globale Optimierung wirklich notwendig ist. PS. Windows ist nicht perfekt, aber ein gutes BS mit brauchbaren Tools. Das muss man nicht immer mit Linux vergleichen.
Udo K. schrieb: > Du musst halt schauen, wo die Zeit genau draufgeht. > Compiliere mal mit -Bt, da siehst du die Zeiten im Log. ich benutzte /Bt+ und /d1reportTime beim kompilieren und /time+ für den Linker da kommt dann ein riesiges 6GB Log raus das ich mit einem Parser zerlege und eine Sqlite fülle mit alle Daten zu Projekten/Cpps(Includes/Classes/Functions)/Linkzeiten usw. das ist die Grundlage für mein Chart-Tool d.h. ich kann genau sage -welches Projekt wie lange gebaut hat -welche cpp da drinn sind wie langen die in Frontend/Backend brauchen -welche VStudio/3rd-Party und eigene Includes(Tree) dran haengen mit Frontendzeit usw. zusätzlich wird noch zu jeder Datei die größe mit geloggt, d.h. hpp,cpp,obj,pch,exe,dll,lib - um zu schauen ob da über die Zeit ein ungewöhnliches Wachstum zu erkennen ist und es sieht so aus als wenn einfach alle cpp Dateien länger bauen d.h. alle Projekte sind in der Kompilierzeit rauf gegangen in Summe eben um 30min (oder 2.5h bei Single-Core) Bevor ich mich in die Detail-Analyse stürze wollte ich nachfragen ob jemand anderes auch solche Erfahrungen beim VS2015/VS2017 Umstieg gemacht hat - weil das in diesem Projekt schon recht dramatische Kompilezeitveränderung verursacht hat > Wenn das nicht ausreicht, schau dir den ProcessMonitor an. > Es gibt auch Tools, die noch mehr können. > Da wird im Detail aufgelistet, was ein Program macht, und wie > lange es dauert. d.h. ich soll mir anschauen was der Link.exe und Cl.Exe und MSbuild.exe prozess so macht, schlafen die viel, voll ausgelastet, usw. werde ich machen > PS. Windows ist nicht perfekt, aber ein gutes BS mit brauchbaren Tools. > Das muss man nicht immer mit Linux vergleichen. habe ich auch nur geschrieben damit ich nicht wieder ewig mit den Leuten über Linux usw. diskutieren muss - weil es einfach Leute gibt die nicht verstehen das der Mark sauber aufgeteilt ist zwischen den beiden Systemen - und sich daran auch nichts rütteln lässt, noch dazu versucht Microsoft das alte böse Verhalten schon zu ändern - z.B. Reaktion auf Bugs, integration von Clang, usw. es ist nicht mehr alles so wie vor 10 Jahren
Wenn möglich probiere doch mal die neuesten Tools (2019 oder 2020) aus, ob die das Problem nicht schon gelöst haben. Eine kurze Google Suche hat einen brauchbaren Hinweis geliefert: Anscheinend werden bei VS2017 sehr viele Zwischenergebnisse hin- und herkopiert. The easiest way to fix it for something like this is to just add a common import and set a property "DoNotCopyLocalIfInGac" to true. With Visual Studio 2017 you can add a file "Directory.Build.props" at the root of your source repository and it will be imported without having to change any of your project files. The file can look something like this: <Project> <PropertyGroup> <DoNotCopyLocalIfInGac>true</DoNotCopyLocalIfInGac> </PropertyGroup> </Project> The other alternative is to set Copy Local to false. To do that right click on the reference in Visual Studio and go to Properties. You should see an entry for Copy Local. The default is to not specify a value which is what is happening here (default value was false because it happened to be in the GAC, but now the default is true for those references). For an upgrade case though I would probably recommend doing the first option. Wenn das nichts bringt, oder nicht genug bringt, schau dir mal die Compilezeiten eines sehr kleinen überschaubaren Projekts an, und versuche rauszufinden, was genau bei VS2017 soviel länger dauert als bei VS2015. Die Referenz oben sagt, das es mit dem Build Prozess (MSBuild) und nicht mit dem Compiler zusammenhängt. Mache das mal händisch, und berichte.
Udo K. schrieb: > Wenn möglich probiere doch mal die neuesten Tools (2019 oder 2020) > aus, VS2019 kommt als nächstes - da überschlagen sich die Blogs ja mit Optimierungen beim Kompiler und Linker > Eine kurze Google Suche hat einen brauchbaren Hinweis geliefert: > > Anscheinend werden bei VS2017 sehr viele Zwischenergebnisse hin- und > herkopiert. > > The easiest way to fix it for something like this is to just add a > common import and set a property "DoNotCopyLocalIfInGac" to true. With > Visual Studio 2017 you can add a file "Directory.Build.props" at the > root of your source repository and it will be imported without having to > change any of your project files. The file can look something like this: ich dachte der GAC - Global Assembly Cache hat nur bedeutung für .Net Sachen - muss ich mir noch mal anschauen > Wenn das nichts bringt, oder nicht genug bringt, schau dir mal die > Compilezeiten eines sehr kleinen überschaubaren Projekts an, > und versuche rauszufinden, was genau bei VS2017 soviel länger dauert > als bei VS2015. > Die Referenz oben sagt, das es mit dem Build Prozess (MSBuild) und nicht > mit dem Compiler zusammenhängt. Mache das mal händisch, und berichte. ich probier mal etwas zusammen zu stellen das Unterschiede zeigt
Bei kleinen Projekten sind die Unterschiede kaum zu merken Ich denke das sinnvollste ist wohl eine Art Code Generator plus CMake damit ich mir künstliche aber skalierbare (Quelltext und Anzahl Libs) Solutions fuer Vs2015,17 und 19 generieren kann - kennt da jemand was passendes so wie csmith: https://embed.cs.utah.edu/csmith/ nur fuer C++?
Wenn du wirklich Speed brauchst, empfehle ich dir Visual Studio 2005 (nicht 2015!). Der geht ab wie Schmidts Katze.
Containment schrieb: > Wenn du wirklich Speed brauchst, empfehle ich dir Visual Studio > 2005 > (nicht 2015!). Der geht ab wie Schmidts Katze. Von dem C++14 Code bekommt der Bauchschmerzen
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.