|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
Всем привет! У такой вопрос Есть у меня unordered_map<string, что-то> um_ в классе. Объекты этого класса в реал-тайм опрашиваются um_[ключ] Данных в um_ порядка 3-15, ну 100 максимум. Самих объектов класса может быть много, 1К-100К, опрос делается по таймеру, цель - избежать лагов. Пока вопрос только по работе с мапой. В голову приходят 2 подхода, с т.з. производительности. 1. Код: plaintext 1. 2. 3. 4. 5.
в этом случае, если в um_ нету ничего соотвествующего "ключу", там заведётся пустой объект, мапа разрастётся, и плюс в коде нужна одна проверка на nullptr; 2. Код: plaintext 1. 2. 3. 4. 5. 6.
тут проверки нет, мапа не разрастается, но ходят холивары на тему быстродействий при использовании исключений. Возможно есть ещё варианты? Как лучше сделать, в рамках задачи? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2018, 10:43 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
1. Сводится во всех случаях к _Try_emplace, которая работает через find, и там всё равно есть проверка на end(), поэтому можно просто сразу пользоваться find() ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2018, 11:11 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
CEMbВсем привет! У такой вопрос Есть у меня unordered_map<string, что-то> um_ в классе. Объекты этого класса в реал-тайм опрашиваются um_[ключ] Данных в um_ порядка 3-15, ну 100 максимум. Самих объектов класса может быть много, 1К-100К, опрос делается по таймеру, цель - избежать лагов. Пока вопрос только по работе с мапой. В голову приходят 2 подхода, с т.з. производительности. 1. Код: plaintext 1. 2. 3. 4. 5.
в этом случае, если в um_ нету ничего соотвествующего "ключу", там заведётся пустой объект, мапа разрастётся, и плюс в коде нужна одна проверка на nullptr; 2. Код: plaintext 1. 2. 3. 4. 5. 6.
тут проверки нет, мапа не разрастается, но ходят холивары на тему быстродействий при использовании исключений. Возможно есть ещё варианты? Как лучше сделать, в рамках задачи? Бредовый вопрос, но вообще-то если тебе нужна скорость, прежде всего надо избавиться от operator[] и использовать методы доступа к значениям в функциональных нотациях. Т.е. фукнции испльзовать. at() find() и так далее. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2018, 15:33 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
MasterZivCEMbВсем привет! У такой вопрос Есть у меня unordered_map<string, что-то> um_ в классе. Объекты этого класса в реал-тайм опрашиваются um_[ключ] Данных в um_ порядка 3-15, ну 100 максимум. Самих объектов класса может быть много, 1К-100К, опрос делается по таймеру, цель - избежать лагов. Пока вопрос только по работе с мапой. В голову приходят 2 подхода, с т.з. производительности. 1. Код: plaintext 1. 2. 3. 4. 5.
в этом случае, если в um_ нету ничего соотвествующего "ключу", там заведётся пустой объект, мапа разрастётся, и плюс в коде нужна одна проверка на nullptr; 2. Код: plaintext 1. 2. 3. 4. 5. 6.
тут проверки нет, мапа не разрастается, но ходят холивары на тему быстродействий при использовании исключений. Возможно есть ещё варианты? Как лучше сделать, в рамках задачи? Бредовый вопрос, но вообще-то если тебе нужна скорость, прежде всего надо избавиться от operator[] и использовать методы доступа к значениям в функциональных нотациях. Т.е. фукнции испльзовать. at() find() и так далее. А чем плохи операторы ? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.08.2018, 13:08 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
semen.s.semenА чем плохи операторы ? Семантика у них сложная... https://en.cppreference.com/w/cpp/container/unordered_map/operator_at ... |
|||
:
Нравится:
Не нравится:
|
|||
07.08.2018, 15:41 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
ключ стрингом не делать ... |
|||
:
Нравится:
Не нравится:
|
|||
07.08.2018, 16:33 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
Siemarglключ стрингом не делатьключ потом будет hash от string. Делать не стрингом его не удобно, они описываются во конфигаруционных файлах людями, а писать на память эту кучу цифр сложно даже мне. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2018, 06:49 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
CEMbhash от stringхотя, подозреваю, оно уже там так и есть ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2018, 06:50 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
CEMb, в плане производительности очень хорошо знать желаемое количество ключей и выделять под них необходимое место заранее - reserve , тогда в идеале не будет перестройки таблицы по поводу использования в виде кэша, MasterZiv написал вариант с исключениями вполне живой, но где ни будь в питоне (там сам использовал, работало быстрее, специально проверял) ну и ещё такое ИМХО, unordered_map нельзя использовать на дополнение при действиях с контентом который может нести угрозу - например, на сервере при контейнеризации переданных параметров ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2018, 08:40 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
CEMb, если их 3-15, то наверное лучше их хранить в обычном векторе(или подобном контэйнере). потому что в мапе они могут быть раскиданы по куче и поиск будет со скоростью шины. Ну и строки заменить на специальные объекты, которые бы хранили свои данные не на куче, а там, где они расположены. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2018, 09:08 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
kealon(Ruslan)хорошо знать желаемое количество ключейувы, там random. kealon(Ruslan)тогда в идеале не будет перестройки таблицыа разве unordered_map перестраивается? kealon(Ruslan)вариант с исключениями вполне живойа почему говорят, что исключения медленно работают? Много раз натыкался на споры на форумах. Или исключения тоже надо уметь готовить правильно? alex_kесли их 3-15, то наверное лучше их хранить в обычном векторея взял unordered_map из соображений быстрого поиска по ключу. В случае вектора придётся это делать перебором. alex_kпотому что в мапе они могут быть раскиданы по куче и поиск будет со скоростью шины.я в своё время тестировал поиск по этой мапе, у неё довольно шустрые показатели при огромных размерах. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2018, 07:17 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
CEMbkealon(Ruslan)тогда в идеале не будет перестройки таблицыа разве unordered_map перестраивается?конечно CEMbkealon(Ruslan)вариант с исключениями вполне живойа почему говорят, что исключения медленно работают? Много раз натыкался на споры на форумах. Или исключения тоже надо уметь готовить правильно?Там всё очень мутно, особенно на x64. Но для питона ИМХО это чистая арифметика из-за особенностей языка: вызвать что-то это нужно из того же мапа переменных достать переменную, а потом достать из неё - это 2 операции а проверить и достать уже выходит 4 т.е. если исходить из особенностей использования кеша, ты гарантировано будешь проигрывать ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2018, 11:25 |
|
CookBook: unordered_map
|
|||
---|---|---|---|
#18+
А кто-нибудь измерял или так знает? std::unordered_multimap::equal_range - работает быстрее, чем перебирать? т.е. мне надо найти элемент по ключу и по ещё одному условию. Я могу использовать std::unordered_multimap::equal_range, потом перебрать по условию. А могу сразу перебрать всю мапу по ключу и по условию. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 20:47 |
|
|
start [/forum/topic.php?fid=57&fpage=16&tid=2017746]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
24ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 262ms |
total: | 389ms |
0 / 0 |