Astra SE v.1.4, Qt v. 5.3. В рамках создания виртуалки из реалки - выяснилось, что виртуальный поток/процессор работает медленнее реального (+ потеря 400МГц при замене оборудования со старого на новое).

Пока решения данной проблемы - нет. Поэтому, было принято решение ускорить сборку гигантского проекта внутри виртуалки (десяток минут - много раз в день) - получилось настолько быстро, что после выхода из отпуска - охренеют программисты нескольких секторов. Жаль, премию не дадут, т.к. начальникам пофиг.

Плоды понимания многопоточности проекта Qt ассоциативно привели к ускорению самой Qt: так же усомниться в корректности настроек по умолчанию - и изменить их по своему усмотрению. Если в исходниках это решилось добавлением инклудов и строк, то в самом Qt - изменением параметров проекта, как изменение самой Qt.

Проекты → Сборка и запуск → Сборка → Настройки сборки → Этапы сборки → Сборка → развернуть Подробнее → Параметры make: -j40, где 40 - количество потоков, 100% перекрывающее количество потоков процессора.

Итоги тестирования:

- самая медленная скорость - с -j1;

- скорость без параметра - одинакова с -j1 (ОС всё равно вместо 1 потока использует типа 1.5). Но меньше -j2;

- -j12 (реальное количество потоков процессора, выделенных в виртуалке) одинаковое по скорости с -j40.

Итоговые приросты скорости:

- на виртуалке с 12 потоками - в 4.2 раза на 6-ядерном 12-поточном i7-8700 3.2ГГц. На реалке - в 3 раза на 4-ядерном 8-поточном i7-4790 3.6ГГц;

- в точной оценке скорости - мешают 2 нюанса. 1 поток виртуалка забирает себе навсегда в 100% нагрузку (возможно, связано с шифрованием) - результат должен быть >4.2. Каждый из процессоров - разгоняется в установленной родительской ОС;

- но в дочерней ОС скорость режется до 3.2ГГц, номинальной, - прироста разгона нет (именно поэтому время сборки у этих 2 процессоров при многопоточности получается примерно одинаковым). То есть, если решить эту проблему - число 4.2 улетит в космос.

Выставление приоритета Qt - не влияет на скорость сборки.