Стоимость использования станд.:: карта со станд.:: строковые ключи по сравнению с международными ключами?

Если Вы используете МРТ, то можно записать потоковый код в C или как расширение или как использование рубиново-встроенного драгоценного камня.

11
задан Goles 3 December 2009 в 21:18
поделиться

5 ответов

В дополнение к временной сложности, связанной с уже упомянутым сравнением строк, строковый ключ также вызывает дополнительное выделение памяти каждый раз, когда элемент добавляется в контейнер. В некоторых случаях, например, в высокопараллельных системах, мьютекс глобального распределителя может быть источником проблем с производительностью.

В общем, вы должны выбрать альтернативу, которая имеет наибольший смысл в вашей ситуации, и оптимизировать только на основе фактического тестирования производительности. Общеизвестно, что трудно судить, что станет узким местом.

8
ответ дан 3 December 2019 в 04:52
поделиться

Разница в стоимости будет связана с разницей в стоимости между сравнением двух int и сравнением двух строк.

При сравнении двух строк, вам нужно разыменовать указатель, чтобы перейти к первым символам, и сравнить их. Если они идентичны, вам нужно сравнить вторые символы и так далее. Если ваши строки имеют длинный общий префикс, это может немного замедлить процесс. Однако вряд ли это будет так же быстро, как сравнение целых чисел.

1
ответ дан 3 December 2019 в 04:52
поделиться

Стоимость, конечно, заключается в том, что целые числа могут сравниваться в реальном времени O (1), тогда как строки сравниваются за время O (n) (n - максимальный общий префикс). Кроме того, для хранения строк требуется больше места, чем для хранения целых чисел. Помимо этих очевидных различий, существенных затрат на производительность нет.

1
ответ дан 3 December 2019 в 04:52
поделиться

Алгоритмы анализа асимптотической производительности работают с операциями, которые должны быть выполнены, и стоимостью, которую они добавляют к уравнению. Для этого вам нужно сначала узнать, какие операции выполняются, а затем оценить их стоимость.

Для поиска ключа в сбалансированном двоичном дереве (какие карты оказываются) требуется O (log N) сложный операции. Каждая из этих операций подразумевает сравнение ключа на предмет совпадения и отслеживание соответствующего указателя (дочернего элемента), если ключ не совпадает. Это означает, что общая стоимость пропорциональна log N , умноженным на стоимость этих двух операций. Следующие указатели представляют собой операцию с постоянным временем O (1) , и сравнение ключей зависит от ключа. Для целочисленного ключа сравнения выполняются быстро O (1) . Сравнивать две струны - совсем другая история, Стоимость определения местоположения элемента на карте, содержащей строки, пропорциональна логарифму количества элементов, хранящихся на карте, умноженному на среднюю длину строк, используемых в качестве ключей.

Обратите внимание, что нотация большого О является наиболее подходящей. для использования в качестве инструмента анализа, чтобы определить, как алгоритм будет вести себя при увеличении размера проблемы, но он скрывает многие факты, которые важны для чистой производительности.

В качестве простейшего примера, если вы измените ключ с общей строки на массив из 1000 символов, вы можете скрыть эту стоимость внутри константы, выпавшей из нотации. Сравнение массивов из 1000 символов - постоянная операция, которая занимает довольно много времени. В асимптотической записи это будет просто операция O (log N) , как с целыми числами.

То же самое происходит со многими другими скрытыми затратами, такими как затраты на создание элементов, которые обычно рассматриваются как операции с постоянным временем, просто потому, что они не зависят от параметров вашей проблемы (затраты на обнаружение блока объем памяти в каждом распределении не зависит от вашего набора данных, а скорее от фрагментации памяти, которая выходит за рамки анализа алгоритма, затрат на получение блокировки внутри malloc, чтобы гарантировать, что не два процесса попытаются вернуть один и тот же блок память зависит от состояния блокировки, которое зависит от количества процессоров, процессов и от того, сколько запросов памяти они выполняют ... что опять же выходит за рамки анализа алгоритма). Читая стоимость в нотации большого О, вы должны осознавать, что это на самом деле означает.

как стоимость создания элементов, которая обычно рассматривается как операция с постоянным временем, просто потому, что она не зависит от параметров вашей проблемы (стоимость размещения блока памяти в каждом распределении не зависит от вашего набора данных, а скорее из-за фрагментации памяти, которая выходит за рамки анализа алгоритма, стоимость получения блокировки внутри malloc, чтобы гарантировать, что не два процесса попытаются вернуть один и тот же блок памяти, зависит от состязания блокировки, которое зависит от самого номера процессоров, процессов и объем выполняемых ими запросов к памяти ... опять же за рамками анализа алгоритма). Читая стоимость в нотации большого О, вы должны осознавать, что это на самом деле означает.

как стоимость создания элементов, которая обычно рассматривается как операция с постоянным временем, просто потому, что она не зависит от параметров вашей проблемы (стоимость размещения блока памяти в каждом распределении не зависит от вашего набора данных, а скорее из-за фрагментации памяти, которая выходит за рамки анализа алгоритма, стоимость получения блокировки внутри malloc, чтобы гарантировать, что не два процесса попытаются вернуть один и тот же блок памяти, зависит от состязания блокировки, которое зависит от самого номера процессоров, процессов и объем выполняемых ими запросов к памяти ... опять же за рамками анализа алгоритма). Читая стоимость в нотации большого О, вы должны осознавать, что это на самом деле означает.

просто потому, что это не зависит от параметров вашей проблемы (стоимость размещения блока памяти в каждом распределении не зависит от вашего набора данных, а скорее от фрагментации памяти, которая выходит за рамки анализа алгоритма, стоимость получения блокировки внутри malloc, чтобы гарантировать, что ни один из двух процессов не попытается вернуть один и тот же блок памяти, зависит от наличия блокировки, которая зависит от количества процессоров, процессов и того, сколько запросов памяти они выполняют ..., снова из объем анализа алгоритма). Читая стоимость в нотации большого O, вы должны осознавать, что это на самом деле означает.

просто потому, что это не зависит от параметров вашей проблемы (стоимость размещения блока памяти в каждом выделении не зависит от вашего набора данных, а скорее от фрагментации памяти, которая выходит за рамки анализа алгоритма, стоимость получения блокировки внутри malloc, чтобы гарантировать, что не два процесса попытаются вернуть один и тот же блок памяти, зависит от конкуренции блокировки, которая зависит от количества процессоров, процессов и того, сколько запросов к памяти они выполняют ..., опять же из объем анализа алгоритма). Читая стоимость в нотации большого O, вы должны осознавать, что это на самом деле означает.

Стоимость получения блокировки внутри malloc, чтобы гарантировать, что не два процесса попытаются вернуть один и тот же блок памяти, зависит от конкуренции за блокировку, которая зависит от количества процессоров, процессов и того, сколько запросов памяти они выполняют ... выходит за рамки анализа алгоритма). Читая стоимость в нотации большого О, вы должны осознавать, что это на самом деле означает.

Стоимость получения блокировки внутри malloc, чтобы гарантировать, что не два процесса попытаются вернуть один и тот же блок памяти, зависит от конкуренции за блокировку, которая зависит от количества процессоров, процессов и того, сколько запросов памяти они выполняют ... выходит за рамки анализа алгоритма). Читая стоимость в нотации большого О, вы должны осознавать, что это на самом деле означает.

13
ответ дан 3 December 2019 в 04:52
поделиться

Прежде всего, я сомневаюсь, что в реальном приложении, есть ли у вас строковые ключи или ключи типа int, имеет какое-либо заметное значение. Профилирование вашего приложения покажет вам, имеет ли это значение.

Если это имеет значение, вы можете изменить свой ключ на что-то вроде этого (непроверено):

class Key {
public:
    unsigned hash;
    std::string s;

    int cmp(const Key& other) {
        int diff = hash - other.hash;
        if (diff == 0)
            diff = strcmp(s, other.s);
        return diff;
}

Теперь вы проводите сравнение int хэшей двух строк. Если хеши разные, значит, и строки разные. Если хэши одинаковы, вам все равно придется сравнивать строки из-за принципа голубятни .

0
ответ дан 3 December 2019 в 04:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: