Wir haben eine große Codebasis, die boost :: signals seit Jahren erfolgreich einsetzt. Wir sind vor Kurzem dazu übergegangen, v1.54 zu verbessern und entschieden, dass Boost :: signals2 nicht mehr verwendet werden sollte und wir zu boost :: signals2 wechseln würden.
Das Problem, das wir sehen, ist, dass die Kompilierungszeiten entsetzlich sind. Beispielsweise dauert eine kleine CPP-Datei jetzt mehr als 20 Sekunden, in denen sie früher 4 war.
In ähnlicher Weise dauert eine unserer Bibliotheken (groß), die bisher etwa 10 Minuten zum Generieren benötigten, bis zu einer Stunde. Ich habe rundherum nach Dokumentation gesucht, wie man dies durch vorkompilierte Header, Makros usw. verbessern kann, aber habe noch nichts gefunden, was die Situation stark verbessert.
Das Anzeigen von cl.exe in procmon zeigt eine enorme Menge an IO in den boost :: signals2 und mpl Bibliotheken.
Wir brauchen nicht die Thread-Sicherheit, die signals2 an diesem Punkt bietet. Wir sind kurz davor, den Stecker des "Upgrades" zu ziehen und zu Signalen zurückzukehren. Hat jemand irgendwelche Vorschläge oder Erfahrungen damit, bevor wir aufgeben?
Wir verwenden VS2012 mit viel RAM / Festplatte / etc.
In einem Projekt, an dem ich gearbeitet habe, waren alle Boost-Signale verpfuscht, so dass Vorwärtsdeklarationen ausreichen. Dies reduziert die Kompilierzeit erheblich, da die signals2-Definitionen nur analysiert werden, wenn sie tatsächlich benötigt werden. Anstatt ein öffentliches boost::signals2::signal -Member bereitzustellen, verfügt die Klasse über ein privates std :: unique_pointer-Member und stellt eine öffentliche connectToX-Funktion bereit, die ein std :: unique_pointer-Objekt zurückgibt.
wird dann zu einem Header mit nur Vorwärtsdeklarationen und keinen Includes von Boost-Signalen2-Headern:
%Vor%Klassen, die nicht an Signalen interessiert sind, müssen nun keine signals2-Header analysieren. Es ist erwähnenswert, dass nach meiner Erfahrung die meiste Zeit nicht im Compiler, sondern im Linker geparst wird. Jede Kompilierungseinheit, die Boost-Signale verwendet, enthält viele instanziierte Funktionen, die Debug-Informationen erzeugen und am Ende durch den Linker eliminiert werden müssen. Und da der MS-Linker single-threaded und wirklich langsam ist, ist dies der Punkt, an dem die Zeit für IO ausgegeben wird. Eine SSD sorgte hier für eine schöne Beschleunigung.
Tags und Links compilation c++ visual-studio-2012 performance boost