Recentemente ho trovato boost :: multi_index_container e sono curioso delle sue prestazioni rispetto alla mia implementazione di un contenitore simile basato su mappatura multi-livello e definito come:Boost multi-index container vs un contenitore di mappatura multi-livello basato su std :: unordered_map (mappa delle mappe)
typedef int Data;
typedef uint64_t MainKey;
typedef uint64_t SecondaryKey;
typedef std::unordered_map<SecondaryKey, Data> SecondaryMap;
typedef std::unordered_map<PrimaryKey, SecondaryMap> PrimaryMap;
L'ordine delle chiavi non è importante. La ricerca rapida è importante e per questo sto usando qualcosa come:
// find primaryKey=10 and secondaryKey=30
PrimaryMap m;
....
auto i1 = m.find(10);
if (i1 != m.end())
{
auto& secondary = i1->second;
auto i2 = secondary.find(30);
if (i2 != secondary.end())
{
found = true;
....
}
}
Mi piacerebbe sapere che cosa sarebbe
- la configurazione più vicina di boost :: multi_index_container per abbinare il mio implementazione
- il modo più veloce per eseguire la ricerca per chiave primaria e secondaria.
Ho provato a configurare il modello, ma non sono sicuro se questa è la soluzione migliore:
struct RecordKey
{
MainKey mainKey;
SecondaryKey secondaryKey;
RecordKey(const MainKey mainKey, SecondaryKey secondaryKey):
mainKey(mainKey),
secondaryKey(secondaryKey)
{}
};
struct Record: public RecordKey
{
Data data;
Record(const MainKey mainKey = 0, const SecondaryKey secondaryKey = 0, const Data& data = 0):
RecordKey(mainKey, secondaryKey),
data(data)
{}
};
struct MainKeyTag {};
struct SecondaryKeyTag {};
struct CompositeKeyTag {};
using boost::multi_index_container;
using namespace boost::multi_index;
typedef boost::multi_index_container<Record,
indexed_by < /*random_access<>,*/
hashed_non_unique<tag<MainKeyTag>, BOOST_MULTI_INDEX_MEMBER(RecordKey, MainKey, mainKey) >,
hashed_non_unique<tag<SecondaryKeyTag>, BOOST_MULTI_INDEX_MEMBER(RecordKey, SecondaryKey, secondaryKey) >,
hashed_unique<tag<CompositeKeyTag>, composite_key<Record, member<RecordKey, MainKey, &RecordKey::mainKey>,
member<RecordKey, SecondaryKey, &RecordKey::secondaryKey> > > > > RecordContainer;
Grazie, ma stai suggerendo che la variante ordinata non ha penalizzazioni prestazionali per la ricerca rispetto alla variante con hash? Voglio fare test delle prestazioni per scoprire quale è più veloce, aumentare il contenitore multi-indice o la mia stessa costruzione. Avrei bisogno di un indice per la chiave primaria e indice per la chiave secondaria e un indice combinato per entrambe le chiavi. L'hash IMHO dovrebbe essere più veloce di quello ordinato. – Flaviu
@Flaviu ordinato vs hash dipende sempre da schemi di accesso.Ma vedendo come sembri pensare che una mappa delle mappe si adatti ai tuoi schemi di accesso, sono abbastanza fiducioso che i compositi ordinati sono una buona corrispondenza (è quello che vuoi, usando solo due ricerche binarie in cascata). Se tu/anche/richiedi la ricerca diretta tramite il composito completo, potresti considerare di aggiungere anche un indice composito *** con hash ***. Tuttavia, tieni presente che questo avrà un overhead non banale su ciascuna operazione di modifica (chiave) sul contenitore. – sehe
Sono stato in grado di inserire e cercare un boost ordinato :: multi_index_container ma stavo cercando una soluzione hash o random_access. La configurazione della chiave composita con hash è la più vicina alla mia costruzione per quanto riguarda la ricerca? – Flaviu