C++: VS2017 kompiliert viel langsamer als VS2015?

-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 !!!!

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

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++?

schon gefunden: https://github.com/intel/yarpgen

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