Подход к проектированию, данные таблицы строк, переменные, использование памяти stl

Question

У меня есть старый класс структуры, как это: typedef vector<vector<string>> VARTYPE_T; который работает как одна переменная. Эта переменная может содержать от одного значения в списке до данных, подобных таблице. Большинство значений long, double, string или double [3] для координат (x,y,z). Я просто конвертирую их по мере необходимости. Переменные управляются на карте следующим образом: map<string,VARTYPE_T *> где строка содержит имя переменной. Конечно, они завернуты в классы. Также у меня есть дерево узлов, где каждый узел может содержать одну из этих переменных карт.

Используя VS 2008 SP1 для этого, я обнаружил много фрагментации памяти. Сравнивая со stlport, stlport казался быстрее (20%) и использует меньше памяти (30%, для моих тестовых случаев).

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

Заранее спасибо,

Howie

Answer 1

+ Изменить typedef vector<vector<string>> VARTYPE_T; в typedef deque<deque<string>> VARTYPE_T; и проверьте, есть ли еще фрагментация памяти.

Кстати, как вы оцениваете это с VS 2008 SP1?

Обновление: я знаю, как HP справляется с фрагментацией памяти HP-UX. После некоторых поисков я нашел интересную ссылку " Куча низкой фрагментации". Это цитата: The low-fragmentation heap (LFH) helps to reduce heap fragmentation, Мне это интересно, так как оно напоминает подход HP к фрагментации памяти, судя по его описанию. Я думаю (кроме использования deque) это еще одна хорошая идея, чтобы попробовать и проверить. `

Обновление 2:1) Скорость. Раньше ты ничего не говорил о скорости, поэтому у меня нет никаких советов, чтобы дать тебе хороший совет. Я также не знаю, где ваша программа проводит большую часть времени, выполняя.

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

2) Использование памяти. Вы на самом деле пишете серверное приложение, работающее в течение нескольких дней, и вас должно беспокоить потребление памяти? Тогда я уже говорил вам, используйте Low-fragmentation Heap на Windows и попробуйте использовать размеры блоков меньше 16K. Также избавьтесь от утечек памяти. Конечно проверь но насколько я понимаю Low-fragmentation Heap Обращаюсь к вам новости.

3) Если вы пишете серверное приложение, тогда std::vector иногда не является хорошим выбором. Он выделяет память в одном блоке. Если оно больше 16K, это может привести к фрагментации памяти.

4) Наконец, посмотрите, как выглядит хороший отчет от HP-UX о распределении памяти (чтобы найти фрагментацию памяти):

Actual Heap Usage:
    Heap Start  =   0x60000000000fea38
    Heap End    =   0x6000000026580000
    Heap Size   =   642258376 bytes

Outstanding Allocations:
    251948524 bytes allocated in 4239425 blocks
                              Detailed Report

-------------------------------------------------------------------------
65343264 bytes in 1361318 blocks (25.94% of all bytes allocated)
These range in size from 48 to 48 bytes and are allocated
#0  stlp_std::__malloc_alloc::allocate(unsigned long&)   from ./libstlport.so.5.1
#1  boost::multi_index::detail::ordered_index<boost::multi_index::identity<csubs::clnt_tax_hist_t>, stlp_std::less<csubs::clnt_tax_hist_t>, boost::multi_index::detail::nth_layer<1, csubs::clnt_tax_hist_t, boost::multi_index::indexed_by<boost::multi_index::ordered_non_unique<boost::multi_index::identity<csubs::clnt_tax_hist_t>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, hrs_allocator::counting_allocator<csubs::clnt_tax_hist_t, (hrs_allocator::allocator_enums)9> >, boost::mpl::vector0<mpl_::na>, boost::multi_index::detail::ordered_non_unique_tag>::insert(csubs::clnt_tax_hist_t const&)   at _alloc.h:381



-------------------------------------------------------------------------
47510512 bytes in 848402 blocks (18.86% of all bytes allocated)
These range in size from 56 to 56 bytes and are allocated
#0  stlp_std::__malloc_alloc::allocate(unsigned long&)   from ./libstlport.so.5.1
#1  csubs::cache_impl<csubs::subs_data_t, csubs::search_policy_range<false>, csubs::erase_policy_range, hrs_allocator::counting_allocator<csubs::subs_data_t, (hrs_allocator::allocator_enums)5>, boost::multi_index::multi_index_container<csubs::subs_data_t, boost::multi_index::indexed_by<boost::multi_index::ordered_non_unique<boost::multi_index::identity<csubs::subs_data_t>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, hrs_allocator::counting_allocator<csubs::subs_data_t, (hrs_allocator::allocator_enums)5> > >::put(csubs::subs_data_t const&)   at _alloc.h:381
#2  csubs::db_cache_loader<csubs::cache_impl<csubs::subs_data_t, csubs::search_policy_range<false>, csubs::erase_policy_range, hrs_allocator::counting_allocator<csubs::subs_data_t, (hrs_allocator::allocator_enums)5>, boost::multi_index::multi_index_container<csubs::subs_data_t, boost::multi_index::indexed_by<boost::multi_index::ordered_non_unique<boost::multi_index::identity<csubs::subs_data_t>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, hrs_allocator::counting_allocator<csubs::subs_data_t, (hrs_allocator::allocator_enums)5> > >, csubs::ctrl_loader_nocheck>::operation()   at cache_subs_loaders.h:121
#3  csubs::group_subs_cache::load_caches_from_db(db_date const&, csubs::cache_options const&, otl_connect&, csubs::cache_stat*)   at ./caches/cache_subs_caches.cpp:1452

и так далее.