Здравствуйте, alex_public, Вы писали:

_>А ты случаем не путаешь медленные вычисления и замораживание интерфейса при таких вычислениях (естественно в том случае, если это писал криворукий программист)? ))) Потому как от второй проблемы расстановка дополнительных циклов обработки сообщений ещё может помочь, а вот с первой проблемой ничем подобным помочь нельзя. А то бы иначе сейчас все суперкомпьютеры выстроились в очередь за "прокачкой сообщений от ОС"...
Hint: multithreading — это единственное решение данной проблемы в Production.

_>Самое забавное, что ты даже не понял что ты собственно сделал в своём и почему он снова заработал. ) И тебя даже не смущает тот факт, что если заменить цикл обработки сообщений на какой-нибудь cout<<"xaxa"; то всё равно проблема решается.

Sorry, но это ты не понял:
Любой "оконный" вывод в современных графических операционных системах связан с обменом сообщениями операционной системы.
Без них не отработает ничего(ни вывод std::cout на консоль, ни обновление прогресс бара).
В данном случае, этот вывод (за счёт прокачки сообщений реализованной в недрах OS Windows) просто обеспечивал "сторонний эффект".
Только вот тут редкий случай, когда данный "сторонний эффект" действует положительно, а не отрицательно
Когда я явно сделал ту же прокачку — всё вернулось на свои места.

_>Поставь для начала (я использовал не такие, но это самый простой вариант для начальной оценки эффекта) в MinGW опции "-O3 -march=native" — сразу оценишь разницу.
Хорошо, попробую!

_>С таким подходом нельзя даже приближаться к тестам на производительность. И да, дефолтные опции Qt весьма далеки от максимальной эффективности.

Пойми правильно, уважаемый alex_public, что я ведь не собираюсь "с пеной у рта" доказывать, что MSVC — the best
Просто хочу докопаться до истины.
Окажется, что в этом эксперименте оба компилятора примерно одинаковы, или даже MinGW чуть быстрее — милости просим!