Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, alex_public, Вы писали:
_>>А ты случаем не путаешь медленные вычисления и замораживание интерфейса при таких вычислениях (естественно в том случае, если это писал криворукий программист)? ))) Потому как от второй проблемы расстановка дополнительных циклов обработки сообщений ещё может помочь, а вот с первой проблемой ничем подобным помочь нельзя. А то бы иначе сейчас все суперкомпьютеры выстроились в очередь за "прокачкой сообщений от ОС"... 
AG>Hint: multithreading — это единственное решение данной проблемы в Production.
_>>Самое забавное, что ты даже не понял что ты собственно сделал в своём и почему он снова заработал. ) И тебя даже не смущает тот факт, что если заменить цикл обработки сообщений на какой-нибудь cout<<"xaxa"; то всё равно проблема решается.
AG>Sorry, но это ты не понял:
AG>Любой "оконный" вывод в современных графических операционных системах связан с обменом сообщениями операционной системы.
AG>Без них не отработает ничего(ни вывод std::cout на консоль, ни обновление прогресс бара).
AG>В данном случае, этот вывод (за счёт прокачки сообщений реализованной в недрах OS Windows) просто обеспечивал "сторонний эффект".
AG>Только вот тут редкий случай, когда данный "сторонний эффект" действует положительно, а не отрицательно 
AG>Когда я явно сделал ту же прокачку — всё вернулось на свои места.
Весьма странная точка зрения.
Определимся с помощью чего мы делаем замеры, с помощью абсолютного времени или каким-то
образом замеряем время которое дала ОС данному потоку.
Во втором случае очевидно никакие системные/библиотечные вызовы в сторону улучшения показателей влиять не могут,
т.к. либо они увеличивают общее время, если не происходит в процессе их вызова переключение потока,
либо никак не учитываются при расчете времени работы, но косвенно должны ухудшать показатели,
за счет забивания всевозможны кэшей своими данными.
В первом случае (случае учета абсолютного времени) системные вызовы теоритически могут влиять,
т.к. ОС в целях улучшения видимой пользователем latency может чуть уменшать или увеличивать
квант времени приложению, и по какой-то причине может решить что приложение с вызовом ProcessMessages
это приложение с которым работает пользователь, а без этого вызова — background process, у которого
можно динамический приоритет планировщика потоков понизить.
Но разве не стоит просто забить на "первый вариант" и не учитывать при benchmarks?
