Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, Denis, Вы писали:

D>>сложности:
D>>во-первых много элементов
D>>во-вторых GUID как ключ... боюсь медленный поиск по нему будет

КД>Реальный опыт
КД>Число элементов — больше 5 млн.
КД>Ключ 40 байт отображается на 4 байта

КД>Это индексация содержимого файла.

Мда, вот поставили мне оценку. А я ведь тебя обманул

• это оказался не map, а set
  
• индексирует он действительно 40 байт, но хранит DWORD, который указывает на элемент в "сегментном" файле.

Вот в файле как раз и хранятся эти 40 байтные уникальные идентификаторы.

Для этого извращения написан собственный класс сравнения вида

struct TRPL_ObjectKeyIndexComparer
{
 public: //typedefs
  typedef TRPL_ObjectKeyData                        key_type;
  typedef size_t                                    size_type;

  typedef size_type                                 index_type;

  struct tag_key_loader
  {
   virtual void load(index_type index,key_type& key)=0;
  };

 public:
  //ldr - это загрузчик 40-байтных идентификаторов
  TRPL_ObjectKeyIndexComparer(tag_key_loader& ldr)
   :m_ldr(ldr)
  {;}

 public:
  //[i1]<[i2]
  bool operator () (const index_type i1,const index_type i2)const;
  {
   key_type i1_key;
   m_ldr.load(i1,i1_key);//загружаем аргумент с левой стороны

   key_type i2_key;
   m_ldr.load(i2,i2_key);//загружаем аргумент с правой стороны

   return i1_key.compare_key(i2_key)<0;
  }//i1,i2

 private:
  tag_key_loader& m_ldr;
};//struct TRPL_ObjectKeyIndexComparer

//объявление set' а выглядит так
typedef TRPL_ObjectKeyIndexComparer                  tag_element_comparer;
typedef set<index_type,tag_element_comparer>         tag_element_storage_indexes;

КД>Не могу сказать, что работает медленно.
Тормозов действительно особо не наблюдаю. На P4-2.4 512MB

Вот. Признался перед товарищами в обмане (возможно ребенка) и сразу полегчало

А то взял умножил 40*5млн получил 200MB. Перепугался, полез смотреть и не увидел такого пожирания памяти