2010-07-06 14 views
5

Ho il seguente codice (che segue in gran parte il primo esempio qui: http://www.boost.org/doc/libs/1_42_0/libs/multi_index/doc/examples.html)). Per qualche ragione, con solo 10000 inserimenti nel multiindice, occorrono diversi minuti per eseguire il programma. Sto facendo qualcosa di sbagliato o è previsto?Boost multi-index con prestazioni di inserimento lente

struct A 
{ 
    int id; 
    int name; 
    int age; 
    A(int id_,int name_,int age_):id(id_),name(name_),age(age_){} 
}; 


/* tags for accessing the corresponding indices*/ 
struct id{}; 
struct name{}; 
struct age{}; 

typedef multi_index_container< 
    A, 
    indexed_by< 
    ordered_unique< 
     tag<id>, BOOST_MULTI_INDEX_MEMBER(A,int,id)>, 
    ordered_non_unique< 
     tag<name>,BOOST_MULTI_INDEX_MEMBER(A,int,name)>, 
    ordered_non_unique< 
     tag<age>, BOOST_MULTI_INDEX_MEMBER(A,int,age)> > 
> A_set; 



int main() 
{ 
    A_set es; 

    for (int a = 0; a != 10000; a++) { 
    es.insert(A(a,a+1,a+2)); 
    } 
    return 0; 
} 
+1

Imposta la macro NDEBUG? Se lo metto, il codice è velocissimo. – pmr

risposta

11

Siete per caso in grado di compilare in modalità di debug? Finisce nei pressi istantaneamente con la configurazione di rilascio predefinita in Visual Studio 2008. Se si compila in modalità debug e quasi seguito l'esempio alla lettera, compresa la roba pre-processore e aveva ancora questa parte:

#ifndef NDEBUG 
#define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING 
#define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE 
#endif 

Quindi rimuovere/disabilitare queste definizioni velocizzerà significativamente anche i tempi di esecuzione. (Con almeno 180x sulla mia macchina, non mi preoccupavo di lasciarlo finire.) Quali sono le conseguenze della disattivazione o della rimozione di queste cose in una build di debug, non lo so.

+0

Grazie, non mi sono accorto di guardare lì. Probabilmente avrei dovuto includerlo anche nel codice. – tsiki

+0

Grazie! Ho fatto la stessa identica cosa e ho incollato questi dall'esempio ... – nhed

+0

Si noti che 'BOOST_MULTI_INDEX_ENABLE_SAFE_MODE' è fortemente raccomandato per il debug. Non causa il rallentamento che stai vedendo e trova bug sottili nel tuo codice. "BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING' è il colpevole qui. Controlla i bug * nel codice boost * e non dovresti impostarlo a meno che non sospetti che il codice boost sia bacato. – Chronial

1

Dalla mia esperienza con il boost::bi_map (che è a mia conoscenza migliore sulla base dei contenitori multi-index), devo dire che quei contenitori multi-indice sono purtroppo relativamente lento. Questo non è per l'inserimento di prestazioni, tuttavia. Quindi non capisco perché sia ​​così lento nel tuo caso.

Ho eseguito un piccolo benchmark confrontando uno boost::bi_map in due boost::unordered_map s. L'inserimento di 100.000 valori unici è di circa 1 secondo per entrambi gli approcci. Tuttavia, l'interrogazione di 50000000 valori è di 10 secondi per unordered_map e 26 secondi per la mappa ordinata (che utilizza le chiavi integer). (La nostra migliore struttura dati interna esegue le ricerche in circa 1 secondo).

4

Diversi minuti sembrano molto lenti - Mi aspetterei secondi al massimo per una CPU moderna. Boost tende a utilizzare molte piccole funzioni che in una build di debug vengono eseguite molto più lentamente di una build di rilascio ottimizzata.

Inoltre, accertarsi che BOOST_MULTI_INDEX_ENABLE_SAFE_MODE e BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING non sono impostate. Entrambi eseguono un controllo runtime aggiuntivo.

Problemi correlati