Причем здесь время реакции системы?
-----
Ну вы же должны показать картинку тому кто смотрит. Мгновенно вы этого сделать не можете. Значит есть время в течении которого произойдет обработка информации и выдача изображения. Само время, для оценки - "задача решена", роли не играет, важно, чтобы система в него гарантированно укладывалась.
В нашем частном случае возможна более эффективная реализация сортировки, чем предлагаемая слишком общими методами из STL.
-----
В вашем "частном случае" необходимо на тех же принципах, на которых построена STL, написать шаблон, реализующий требуемую сортировку, с сохранением традиционных методов STS и использовать именно его для решения задач. Но никак не переходить на "простой Си".
Гол в свои ворота.
-----
Увы, но нет. Не существует задачи, для которой ООП-язык менее приспособлен, чем процедурный. Конкретный тип самого языка - вообще никакой роли не играет.
Единственное, в чем проигрывает ООП-язык - в нем есть небольшой оверхед при вызове виртуальных функций, но он явно не критичен.
Адресное пространство процесса при этом фрагментируется.
-----
Угу... стоит последовать совету - изучить соответствующую документацию. Тогда не будет проблем с фрагментацией.
Данную проблему можно решить "уплотнением"
-----
Еще раз - можно и не улотнять. Читайте документацию.
Годиках этак в 80-х одному мужичку было предложено модифицировать код, который строил в памяти сложную многоразмерную матрицу по исходным данным, потом обсчитывал ее по не слишком сложному алгоритму. Программа, в принципе, была написана, но для работы требовалось иметь "большую" ЕС с 16-ю мегами памяти. От мужичка же требовалось портировать программу на одну из малых машин с 16 килобайтами памяти. Разумеется, вся матрица не вмещалась в память и народ ожидал тех же мучений, которые описываете вы - фрагментация, выгрузка-загрузка сегментов, кеширование/декеширование и т.п... А мужичек чуть ли не на другой день сдал работающую программу. И она делала именно то, что требовалось и за то время, которое отводилось.