2013-07-13 2 views
1

Я работаю над игрушкой/экспериментом, которая потребует DNS-сервиса для определения местоположения/адреса конкретных узлов в локальной сети. Он также сохранит другую информацию, такую ​​как тип узла, тип сокета (enet-udp или tcp) и несколько других конкретных бит данных. большинство (или, возможно, все) в числовых типах. Каждая запись будет связана с конкретным клиентом по идентификатору клиента, причем каждый клиент имеет свой собственный поток в узле.Каковы самые быстрые контейнеры, доступные в boost?

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

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

Неправильное место для этого типа контейнера/конструкции? Это первый раз, когда я должен был быть чрезвычайно придирчивым к структурам в boost или даже C++ в целом, поэтому с нетерпением ожидаем изучения чего-то нового.

Благодаря

+1

Один поток на одного клиента? Звучит неплохо. Явное сохранение состояния хранилища и предоставление потоков по возможностям сервера. Резервирование реального потока за ckient означает медленные переключатели контекста, явное состояние означает, что вам просто нужно переключить состояние. – Yakk

+0

@Yakk - ваше право, но на данный момент нити не будут ничего делать, кроме как говорить. – JSON

+2

Если вы не заботитесь о производительности, то в чем суть вашего вопроса? Микро-оптимизация - плохая идея: напишите ее быстро и свободно, если у вас есть игрушка, и если у вас нет игрушечного фокуса на части, которые * важны *, например, отбрасывание вашего однопоточного за клиентом, а не " что является самым быстрым контейнером ». Контейнер будет узким местом позже, и его нужно будет легко вынуть и поменять с чем-то быстрее, если вам нужно: модель, в которой вы предполагаете, что на основе потока будет не так легко поменяться. – Yakk

ответ

2

Во-первых, просто взять время, чтобы убедиться, что этот поиск является на самом деле собирается быть одним из узких мест вашего приложения (если вы делаете I/O любые внутренние поиски, вероятно, будет неуместным).

Если вы можете установить колпачок (max val) на числовой идентификатор и быть довольным, не увеличивая абсолютный максимум, который вы можете получить, это будет зарезервированный вектор.

В противном случае наиболее вероятным кандидатом будет хэш (unordered_map от C++ 11 или boost). Хэш будет иметь постоянный поиск времени, но обратите внимание на коэффициент загрузки и когда он растет.

+0

unordered_map ia выглядит так, как будто это будет работать для меня. благодаря – JSON

Смежные вопросы