Это будет немного более быстро, поскольку нет этого переданного параметра (хотя стоимость производительности вызова метода является, вероятно, значительно больше, чем это сохранение).
я сказал бы лучшую причину, о которой я могу думать для частных статических методов, то, что это означает, что Вы не можете случайно изменить объект (поскольку нет этого указателя).
Нет, вам следует выполнять вычисления в отдельном потоке. Как вы уже упоминали, в QCoreApplication :: processEvents ()
есть обходной путь, но похоже, что вы не можете заставить это работать на себя.
Если вы не хотите чтобы выполнить всю работу по настройке QThread и перемещению всего кода, вы можете обнаружить, что функция QtConcurrent :: run полезна - она позволяет вам запускать функцию асинхронно.
A Несколько указателей: вы должны стараться, чтобы ваш основной (GUI) поток был как можно более легким. Большие объемы операций ввода-вывода или вычислений должны выполняться либо асинхронно с использованием QtConcurrent :: run, либо выполняться внутри отдельного QThread. В зависимости от сложности вашего кода,
Лучше всего переложить долгие вычисления на другие потоки, чтобы основной поток графического интерфейса оставался отзывчивым. Старый способ однопроцессорной обработки - убедиться, что ваши вычисления никогда не выполняются слишком долго без опроса обработчика событий графического интерфейса, но это не масштабируется для многоядерных процессоров.
К счастью, Qt имеет отличную многопоточность. поддержка . Раньше вам приходилось развертывать собственную систему, например, для передачи задач в пул потоков, используя QThread
, QMutex
, QWaitCondition
и т. Д., но последние выпуски Qt упростили задачу с помощью абстракций более высокого уровня, таких как QThreadPool
, QtConcurrent :: run
и QFuture
.
Я не знаю, как все пойдет, если вы вызовете QApplication :: exec () из другого потока, который затем станет вашим потоком графического интерфейса. Просто идея.
(Сообщите нам, если это сработает, было бы интересно ...)