std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>
-
Ich weiß nicht, ob du auch richtig große Projekte baust, die mehr als ne halbe Stunde dauern. Da lernt man dann irgendwann unter Schmerzen, dass man das Build-Verzeichnis besser in die Ausnahmeliste packt. Das kann sonst durchaus schonmal die vierfache (!) Zeit benötigen. Besonders bei parallelen Builds wo zig- bis hunderttausende kleine Build-Artefakte entstehen und vergehen, die der alle scannen will. "Echtzeit-Schutz merkt man kaum" my ass -
... und selbst ohne Defender sind solche Builds unter Windows ziemlich lahm: Das Dateisystem kann nicht gut mit vielen kleinen Dateien und das OS ist auch nicht gut auf extrem viele kurzlebige Prozesse zu sprechen (ist bei Autotools-Projekten sehr auffällig oder generell Buildskripten, die viele (Unix-)Shellbefehle absetzen).
-
@hustbaer sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Eine Ausnahme für "C:\Program Files (x86)" ist vermutlich weniger schlau.
Nee, als schnellen Fix habe bloß den einen Ordner "C:\Program Files (x86)\Foo\Config" ausgenommen.
Als richtigen Fix werde ich einen Fortschrittsbalken bzw. Splash Screen einbauen.
-
@Finnegan sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Ich weiß nicht, ob du auch richtig große Projekte baust, die mehr als ne halbe Stunde dauern. Da lernt man dann irgendwann unter Schmerzen, dass man das Build-Verzeichnis besser in die Ausnahmeliste packt. Das kann sonst durchaus schonmal die vierfache (!) Zeit benötigen. Besonders bei parallelen Builds wo zig- bis hunderttausende kleine Build-Artefakte entstehen und vergehen, die der alle scannen will.
Das Build Verzeichnis habe ich schon länger in der Ausnahmeliste. Vor einigen Jahren wuchs ein Projekt dermaßen, dass die Build Zeit zwischen 10-15 Minuten dauerte. Also habe ich vorkompilierte Header benutzt, den Code aufgeräumt (Header Beziehungen überprüft), das Build Verzeichnis in die Ausnahmeliste genommen,...
Heute kompiliert mein Projekt in 2 Minuten.
So richtig auffällig bezüglich Virenscanner ist das Android Studio, welcher beim Starten vor Virenscannern warnt.
-
@Finnegan sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Echtzeit-Schutz
Alter Running Gag: Echtzeit kostet echt Zeit.
-
@Quiche-Lorraine sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Das Build Verzeichnis habe ich schon länger in der Ausnahmeliste. Vor einigen Jahren wuchs ein Projekt dermaßen, dass die Build Zeit zwischen 10-15 Minuten dauerte. Also habe ich vorkompilierte Header benutzt, den Code aufgeräumt (Header Beziehungen überprüft), das Build Verzeichnis in die Ausnahmeliste genommen,...
Heute kompiliert mein Projekt in 2 Minuten.
Ich bin heute sogar so weit, dass ich, wenn nicht z.B. sowas wie MSVC vorgegeben ist, die größeren Sachen in einem Linux-Container cross-kompiliere. Das gibt auch nochmal einen gehörigen Schub, wegen der oben erwähnten "vielen kleinen Dateien und Prozesse". WSL2 kann auch helfen (ist ja de facto auch ne Linux-VM), aber nicht immer so zuverlässig, weil manchmal doch noch Zugriffe auf das Windows-Dateisystem stattfinden. Besonders wenn dort der Source Code oder gar das Build-Verzeichnis liegen.
-
Wenn der Source in nem Windows Verzeichnis liegt, dann musst du entweder mit irgendwas ala rsync den Code ins WSL2 Filesystem rüberschieben, oder es wird alles noch viel langsamer.
Ich kann aber auch keinen grossen Slowdown feststellen wenn ich direkt auf Windows baue. Also zumindest nicht bei C++. Da kostet das Parsen der Headerfiles um Grössenordnungen mehr Zeit als das Aufmachen und Einlesen.
-
@hustbaer sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Da kostet das Parsen der Headerfiles um Grössenordnungen mehr Zeit als das Aufmachen und Einlesen.
Vor allen Dingen wenn man eine Header Datei mit hohen Include Abhängigkeiten hat. Wo also in der Header Datei viele Includes stehen und diese von vielen andere Dateien includiert werden.
-
@hustbaer sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Ich kann aber auch keinen grossen Slowdown feststellen wenn ich direkt auf Windows baue. Also zumindest nicht bei C++. Da kostet das Parsen der Headerfiles um Grössenordnungen mehr Zeit als das Aufmachen und Einlesen.
Möglich, dass mein Eindruck von großen Autotools-Projekten rührt (sowas wie ne GCC Toolchain bauen). Da merkt man schon bei der Textausgabe der
configure-Skripte einen deutlichen Unterschied. Man könnte bei dieser Kategorie von Builds auch fast meinen, dass mehr Zeit für Shell-Skripte draufgeht, als fürs eigentliche Kompilieren. Wenn man sich die CPU-Last ansieht, dann ist die während des Builds auch sehr häufig extrem niedrig, bis dann wieder alle Skripte durch sind, das parallelemakeloslegt und die CPU auf 100% bringt.Es kann daher gut sein, dass Builds, die nicht so viel "shell-scripten", auf Windows fast genau so schnell durchlaufen. LLVM als CMake-Projekt wäre da ein gutes Gegenbeispiel. Bei dem habe ich auch den Eindruck, dass der Unterschied nicht ganz so groß ist.
Ich denke aber an meinem Einwand, dass viele Prozesse ein Problem sind, ist durchaus was dran. Ich kann mir das nur durch die ganzen unheilig gepipten
sed,awk,trund was weiss ich was noch alles erklären. Das ist schon extrem, wie viele kurzlebige Prozesse da gestartet werden
Der Eindruck mit den "vielen kleinen Dateien" wird bei mir hauptsächlich bestärkt, wenn ich in der Shell mit großen Source- und Build-Verzeichnissen hantiere (nicht selten > 1 Mio. Dateien). Löschen, Umkopieren, "Greppen". Da spüre ich das auch sehr deutlich. Kann aber gut sein, dass dieser Aspekt beim eigentlichen Kompilieren nicht so stark ins Gewicht fällt.
Bin auch ein Fan des Linux-Dateisystems, weil dort die Dateien nicht "gelockt" werden. Dass man z.B. öfter mal einen Ordner nicht löschen kann, weil noch irgendein Prozess eine Datei darin geöffnet hat, macht den Workflow manchmal ganz schön holprig.
-
@Quiche-Lorraine sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
@hustbaer sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Da kostet das Parsen der Headerfiles um Grössenordnungen mehr Zeit als das Aufmachen und Einlesen.
Vor allen Dingen wenn man eine Header Datei mit hohen Include Abhängigkeiten hat. Wo also in der Header Datei viele Includes stehen und diese von vielen andere Dateien includiert werden.
Ja, klar. Wobei, sogar so "einfache" Sachen wie
iostreamreichen oft schon. Da sind schnell mal ein paar zig bis hundert ms weg.
-
@Finnegan sagte in std::ifstream::open benötigt nach einem Neustart recht lange <gelöst>:
Der Eindruck mit den "vielen kleinen Dateien" wird bei mir hauptsächlich bestärkt, wenn ich in der Shell mit großen Source- und Build-Verzeichnissen hantiere (nicht selten > 1 Mio. Dateien). Löschen, Umkopieren, "Greppen". Da spüre ich das auch sehr deutlich.
Ja, klar, bei sowas ist Linux viel schneller. Vor allem wenn man in einem Unternehmen arbeitet wo neben dem normalen Defender noch die speziellen Enterprise-Features von Defender aufgedreht sind, und dann vielleicht noch zusätzliche Tools wie BeyondTrust. Das kann schon ordentlich bremsen. Weil die meistens die ausgenommenen Verzeichnisse nicht berücksichtigen.
Kann aber gut sein, dass dieser Aspekt beim eigentlichen Kompilieren nicht so stark ins Gewicht fällt.
Ja, kommt immer drauf an. Wenn du mit Ports von klassischen Linux Tools auf Windows baust, dann kann es sein dass es (viel) mehr ins Gewicht fällt. Speziell wenn es noch handgeschriebene Skripte oder Makefiles sind die tausende Prozessstarts machen um dann vielleicht 100 oder 200 reine C Files zu übersetzen.
Das andere Extrem wäre wenn du ein einzelnes grosses C++ Projekt mit MSBuild übersetzt. Ninja sollte auch gut gehen, wobei das hab ich auf Windows noch nicht probiert.
-
@Finnegan
ps: Falls du auf Windows oft grepst, kann ich dirripgrepempfehlen. Das verwendet AFAIK mehrere Threads um parallel Verzeichnisse zu enumerieren, Files zu öffnen und dann zu durchsuchen. Auf jeden Fall ist es ordentlich viel schneller als alle anderen grep Tools auf Windows die ich probiert habe.
