Вход на сайт
программисткие курсы
649 просмотров
Перейти к просмотру всей ветки
в ответ Wlad75 04.12.05 01:07
Если необходимо динамически наращивать массив данных (нет возможности получить приемлемую верхнюю оценку), то применение пары new/delete приводит к резервированию нового блока памяти, переписыванию содержимого, освобождению старого блока. Адресное пространство процесса при этом фрагментируется. Например, если первоначально был зарезервирован блок памяти размером 1GB, затем понадобилось увеличить этот блок до 1.5GB и были использованы new/delete, то в системе будет 1GB свободного адресного пространства, за ним 1.5GB занятого и опять 1.5GB свободного. Последующая попытка увеличить размер зарезервированного блока до 2GB не пройдет, хотя физической памяти может быть достаточно (речь о 32битной системе).
Ваши программисты никогда не слышали о std::deque?
Кроме того, у нас есть проблема фрагментации адресного пространства и, как следствие, невозможность получить новый блок памяти, даже если есть необходимое количество свободной оперативной памяти. За это отдельное спасибо С++ с его бедной подсистемой управления памятью и С++ ассам, динамически создающим тысячи объектов.
Мда... Может вс╦ таки лучше программистов знающих С++ нанять? В любой приличной документации/книге по STL говорится, что стандартный аллокатор неэффективно работает с большим количеством маленьких объектов, лечится это элементарно - написанием собственного аллокатора! Примеры - в любой хорошей книге по C++.
В нашем частном случае возможна более эффективная реализация сортировки, чем предлагаемая слишком общими методами из STL. Они не могут учитывать специфику наших данных.
Это лечится написанием одной! функции-шаблона реализируюшей данный алгоритм сортировки, и дальнейшим использованием данной функции со всеми типами ваших контейнеров.
Гол в свои ворота. Критические ко времени выполнения куски в нашем случае - обработка изображений и других собираемых данных, визуализация - соль проекта и выкинуть не получится.
Гол в Ваши ворота. При правильном написании такие библиотеки зачастую быстрее работают на С++, так как компайлер может проинлайнить разные функторы, что невозможно на С.
Ваши программисты никогда не слышали о std::deque?
Кроме того, у нас есть проблема фрагментации адресного пространства и, как следствие, невозможность получить новый блок памяти, даже если есть необходимое количество свободной оперативной памяти. За это отдельное спасибо С++ с его бедной подсистемой управления памятью и С++ ассам, динамически создающим тысячи объектов.
Мда... Может вс╦ таки лучше программистов знающих С++ нанять? В любой приличной документации/книге по STL говорится, что стандартный аллокатор неэффективно работает с большим количеством маленьких объектов, лечится это элементарно - написанием собственного аллокатора! Примеры - в любой хорошей книге по C++.
В нашем частном случае возможна более эффективная реализация сортировки, чем предлагаемая слишком общими методами из STL. Они не могут учитывать специфику наших данных.
Это лечится написанием одной! функции-шаблона реализируюшей данный алгоритм сортировки, и дальнейшим использованием данной функции со всеми типами ваших контейнеров.
Гол в свои ворота. Критические ко времени выполнения куски в нашем случае - обработка изображений и других собираемых данных, визуализация - соль проекта и выкинуть не получится.
Гол в Ваши ворота. При правильном написании такие библиотеки зачастую быстрее работают на С++, так как компайлер может проинлайнить разные функторы, что невозможно на С.