Tempi di compilazione con boost :: signal2 molto lento

Question

Abbiamo una grande base di codice che ha utilizzato con successo boost :: signals per anni. Recentemente abbiamo deciso di potenziare la v1.54 e abbiamo deciso che, poiché boost: i segnali erano deprecati, avremmo dovuto passare a boost :: signals2.

Il problema che stiamo vedendo è che i tempi di compilazione sono orrendi. Ad esempio, un piccolo file .cpp impiegherà ora più di 20 secondi in cui era necessario 4.

Analogamente, una delle nostre librerie (grande) che impiegava circa 10 minuti per generare ora richiede fino a un'ora. Ho cercato dappertutto la documentazione su come migliorare questo attraverso intestazioni, macro, ecc precompilati, ma non ho ancora trovato nulla che migliori la situazione.

Visualizzazione cl.exe in procmon rivela una grande quantità di IO nelle librerie boost :: signals2 e mpl.

Non abbiamo bisogno della sicurezza del filetto che i segnali2 forniscono a questo punto siamo vicini a staccare la spina dall'aggiornamento e tornare ai segnali. Qualcuno ha qualche suggerimento o esperienza con questo prima di arrenderci?

Usiamo VS2012 con molta RAM/disco/ecc.

Answer 1

In un progetto su cui ho lavorato, tutti gli usi dei segnali di boost erano puntinati in modo tale che le dichiarazioni di inoltro fossero sufficienti. Ciò riduce significativamente il tempo di compilazione poiché le definizioni dei segnali2 vengono analizzate solo quando effettivamente necessarie. Invece di fornire un membro pubblico boost::signals2::signal, la classe ha un membro std :: unique_pointer privato e fornisce una funzione connectToX pubblica che restituisce un oggetto std :: unique_pointer.

class Subject { 
public: 
    boost::signals2::signal<void (int)> valueChanged; 
    void setValue(int x) { 
     valueChanged(x); 
    } 
}; 

class A { 
public: 
    A(Subject& subject): conn(subject.sig.connect([&](int x) {this->onChange(x);}) {} 
    ~A() {conn.disconnect();} 
private: 
    void onChange(x) {} 

    boost::signals2::connection conn; 
}; 

diventa poi un colpo di testa con solo avanti dichiarazioni e non include di spinta intestazioni signals2:

// Header file 
class Subject { 
public: 
    std::unique_ptr<boost::signals2::connection> connect(std::function<void (int)> observer); 

private: 
    class Impl; 
    std::unique_ptr<Impl> mImpl; 
}; 

classi non interessate a segnali ora non c'è bisogno di analizzare le intestazioni signals2. Vale la pena notare che nella mia esperienza la maggior parte del tempo non viene speso nell'analisi del compilatore, ma nel linker. ogni unità di compilazione che utilizza i segnali di boost contiene molte funzioni istanziate che generano informazioni di debug e devono essere eliminate dal linker alla fine. E dato che il linker MS è single-threaded e molto lento, è qui che viene speso il tempo a fare IO. Un SSD ha fornito una buona accelerazione qui.