Есть ли рекомендации по необходимости выноса функции в поток?

[kuzulis]

Всем доброго времени.

Вот, есть некая ф-я, на работу которой затрачивается 1-2 мсек. Есть ли необходимость выноса ее в отдельный поток?
И есть ли вообще рекомендации, когда это нужно делать (каков лимит микросекунд/миллисекунд) чтобы ГУЙ не тормозил?

[Racheengel]

Обычно считается, что от 20 обновлений в секунду человеку трудно увидеть разницу.
Поэтому 50 мсек на функцию - должно быть в пределах нормы.

[Igors]

По моим наблюдениям рекомендация "выноси в поток" дается на все без разбора, мотивировка "чтобы UI не тормозило". Думаю выносить или нет зависит от того есть ли что делать приложению пока ф-ция выполняется. Напр если операция чисто фоновая и может длиться хз сколько, то вынос очевиден. Но часто (если не чаще) бывает что приложению надо дождаться конца или отмены операции, а потом уже что-то решать. Здесь вынос в поток совершенно ни к чему, заморозку UI легко решить повтыкав qApp->processEvents

[Igors]

Обычно считается, что от 20 обновлений в секунду человеку трудно увидеть разницу.
Поэтому 50 мсек на функцию - должно быть в пределах нормы.

Читаем классику  

While an operation generated by a menu item takes place, you need to
provide feedback to the user about what is going on. You can display the
animated watch cursor for immediate feedback if an operation will last only a
short length of time. If the operation takes a bit longer, display a status dialog
box to give the user more feedback about the operation under way. If an
operation takes a long time, be sure to implement it asynchronously so that it
can run in the background. After the operation is completed, return the menu
title to the unhighlighted state.

Keep in mind when you decide your timing issues that people have built-in
expectations about how long they want to wait for an operation to be
completed. Try to provide your users with feedback that lets them know that
the computer is still working

Где-то еще видел: задержка до 2 сек - можно обойтись курсором, больше - надо показывать индикатор

[kuzulis]

заморозку UI легко решить повтыкав qApp->processEvents

Не, ну это понятно... А вот, допустим, что ф-я какая то внешняя, библиотечная, в которую ничто не натыкаешь. Кроме того, она вызывается периодически.

Думаю, что придётся в поток вынести, т.к. кроме неё ещё могут быть и другие аналогичные, тратящие миллисекунды. Если таких ф-й наберётся достаточно, то ЮИ будет фризиться.

Хотя, конечно, лучше пройтись профилировщиком сначала, а потом думать.  

[Igors]

Думаю, что придётся в поток вынести, т.к. кроме неё ещё могут быть и другие аналогичные, тратящие миллисекунды. Если таких ф-й наберётся достаточно, то ЮИ будет фризиться.

Заморозка/разморозка - палка о двух концах. Разгружая нитку UI Вы должны считаться с текущими операциями в др нитках. Напр юзер повторно запускает операцию которая уже выполняется или закрыл окно куда должны прийти данные или вообще хочет выйти из приложения и.т.п. Нередко предусмотреть все оказывается слишком сложным

[qate]

Думаю, что придётся в поток вынести

а какие сложности использовать QtConcurrent ?
там и поток создается и результат вернется, ничего самому делать не нужно

[__Heaven__]

имхо, выносить в поток или нет зависит от ситуации. Я бы не стал выносить в поток ради антифриза ГУИ и функцию, которая работает 3 сек если она всегда вызывается весьма редко.
С другой стороны, если рассматривать сохранение большого объекта в файл и дальнейшее продолжение работы, то можно в поток передать копию сохраняемого объекта.

[kuzulis]

а какие сложности использовать QtConcurrent ?

В принципе - никаких. Кроме как то что прервать нельзя (вроде как).

[__Heaven__]

kuzulis, прервать можно. У вас поток выполнения будет считывать флаг прерывания и прекращать работу в случае истины, а ГУИ, имея указатель на эту переменную, имеет возможность установить в него значение.

[kuzulis]

прервать можно

А если ф-я не моя, и не имеет исходников? (если она резолвится?)  
Туда некуда флаг засовывать.

У вас поток выполнения будет считывать флаг прерывания и прекращать работу в случае истины,
 а ГУИ, имея указатель на эту переменную, имеет возможность установить в него значение.

Это гемморой. Там с мьютексами огород нужен и прочее... (как я понял, предлагается QThread::run() ??).
Я как раз хочу от этого избавиться.

Хочу все асинхронно - запустил ф-ю в треде и забыл про нее... когда она отработает - я просто получу уведомление.
Все!

Плохо что прервать нельзя. По крайней мере в доках написано, что QFutureWatcher, полученный от QtConcurrent::run()
не "канселябельный", но вроде как, полученный от мапы "канселябельный"... Надо поизучать этот момент.

PS: В рассылке мельком видел предложение, чтобы ввести" платформо-специфичные" вещи для возможности
прерывания потока без всяких флагов: http://lists.qt-project.org/pipermail/development/2016-September/026939.html
(хотя, вроде там не об этом речь)

[__Heaven__]

А если ф-я не моя, и не имеет исходников? (если она резолвится?)

Мне кажется, что для такого случая подходит только убить нитку (QtConcurent не предоставляет такой возможности), но это чревато последствиями. Так что, на мой взгляд, такую функцию лучше не прерывать либо вынести её в отдельный исполнительный файл.

Это гемморой. Там с мьютексами огород нужен и прочее...

Если вы хотите просто, чтобы интерфейс не застывал, то мьютексы не понадобятся. У вас запись в переменную ведёт только 1 поток, второй же просто считывает её. Для этого не нужны блокировки.

[kuzulis]

либо вынести её в отдельный исполнительный файл.

Да, кстати, а QProcess - это вариант! Если и крешнится там что-нить из той ф-ции, то это не проблема.  

Пусть тот процесс висит и ждет команд через пайпы и возвращает результат через пайпы..

[Igors]

Да, кстати, а QProcess - это вариант!

Куда понесло? ("пришел за памперсами"  )

Хочу все асинхронно - запустил ф-ю в треде и забыл про нее... когда она отработает - я просто получу уведомление.
Все!

Это хорошо для операций длящихся хотя бы хорошие доли секунды, а иначе - разбазаривание ресурсов, вызов обойдется дороже.

Думаю, что придётся в поток вынести, т.к. кроме неё ещё могут быть и другие аналогичные, тратящие миллисекунды. Если таких ф-й наберётся достаточно, то ЮИ будет фризиться.

Ну и кто мешает воткнуть qApp->processEvents после того как ф-ция вернула управление? Наверное только неукротимое желание познать "многопоточность" 

[Akon]

Имхо, миллисекунды - это ни о чем. Даже если таких функций несколько, и между ними у ГУЯ будет возможность обработать события из очереди, - никаких значимых тормозов.