Причем здесь время реакции системы?

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

Гол в свои ворота. Критические ко времени выполнения куски в нашем случае - обработка изображений и других собираемых данных, визуализация - соль проекта и выкинуть не получится. А настаивание на использовании ООП/ООА/C++ вопреки всем возникающим сопутствующим проблемам как раз и выявляет непонимание задачи и неумение применять имеющиеся средства. Java и C# некоторые тоже пытались протолкнуть, но быстро успокоились после пары провальных экспериментов.

Причем здесь дискрипторы сегментов и vtable? Если необходимо динамически наращивать массив данных (нет возможности получить приемлемую верхнюю оценку), то применение пары new/delete приводит к резервированию нового блока памяти, переписыванию содержимого, освобождению старого блока. Адресное пространство процесса при этом фрагментируется. Например, если первоначально был зарезервирован блок памяти размером 1GB, затем понадобилось увеличить этот блок до 1.5GB и были использованы new/delete, то в системе будет 1GB свободного адресного пространства, за ним 1.5GB занятого и опять 1.5GB свободного. Последующая попытка увеличить размер зарезервированного блока до 2GB не пройдет, хотя физической памяти может быть достаточно (речь о 32битной системе). Данную проблему можно решить "уплотнением" памяти - блок должен быть сдвинут в начало памяти. Но new/delete здесь ничем не помогут. Помимо alloc/free есть еще и функция realloc, при использовании которой в описанной выше ситуации проблема фрагментации адресного пространства просто не возникает. Плюс не происходит ненужное переписывание данных как при использовании new/delete.