LINUX.ORG.RU

История изменений

Исправление AntonI, (текущая версия) :

Я глубоко не копал, но емнип unordered_map<size_t, …> при неограниченном числе бакетов выигрывает у такой же мапы на порядок. Я не очень понимаю за счет чего, мб какая то оптимизация за счет того что ключ целочисленный. Наверное это воспроизводимо и для мапы?

А насколько плотно лежат field3 в рамках одной пары field1,2 и какой у них диапазон?

И насколько важна оптимизация записи в контейнер?

Исправление AntonI, :

Я глубоко не копал, но емнип unordered_map<size_t, …> при неограниченном числе бакетов выигрывает у такой же мапы на порядок. Я не очень понимаю за счет чего, мб какая то оптимизация за счет того что ключ целочисленный. Наверное это воспроизводимо и для мапы?

А насколько плотно лежат field3 в рамках одной пары field1,2 и какой у них диапазон?

Исправление AntonI, :

Я глубоко не копал, но емнип unordered_map<size_t, …> при неограниченном числе бакетов выигрывает у такой же мапы на порядок. Я не очень понимаю за счет чего, мб какая то оптимизация за счет того что тип ключа заранее известен. Наверное это воспроизводимо и для мапы?

А насколько плотно лежат field3 в рамках одной пары field1,2 и какой у них диапазон?

Исправление AntonI, :

Я глубоко не копал, но емнип unordered_map<size_t, …> при неограниченном числе бакетов выигрывает у такой же мапы на порядок. Я не очень понимаю за счет чего, мб какая то оптимизация за счет того что тип ключа заранее известен. Наверное это воспроизводимо и для мапы?

А насколько плотно лежат кей3 и какой у них диапазон?

Исходная версия AntonI, :

Я глубоко не копал, но емнип unordered_map<size_t, …> при неограниченном числе бакетов выигрывает у такой же мапы на порядок. Я не очень понимаю за счет чего, мб какая то оптимизация за счет того что тип ключа заранее известен. Наверное это воспроизводимо и для мапы?