Forum: PC-Programmierung C++: VS2017 kompiliert viel langsamer als VS2015?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
-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

von Rolf M. (rmagnus)


Bewertung
3 lesenswert
nicht lesenswert
cppbert schrieb:
> ~500LOC

Klingt für mich jetzt nicht so arg groß ;)

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> cppbert schrieb:
>> ~500LOC
>
> Klingt für mich jetzt nicht so arg groß ;)

500(K)LOC !!!!

von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
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
von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Udo K. (udok)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von T.roll (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von cppbert (Gast)


Bewertung
5 lesenswert
nicht lesenswert
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:
Hat hier jemand ähnliche Erfahrungen gemacht?

oder darf man auch nicht nach Erfahrungen fragen?

von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Udo K. (udok)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Udo K. (udok)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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++?

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von M.K. B. (mkbit)


Bewertung
0 lesenswert
nicht lesenswert
https://github.com/microsoft/vcperf

Konnte das aber noch nicht selbst ausprobieren.

von Containment (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du wirklich Speed brauchst, empfehle ich dir Visual Studio 2005 
(nicht 2015!). Der geht ab wie Schmidts Katze.

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.