Вы, скорее всего, ошибаетесь в отношении того, что означает «критическое время» и где ваше приложение фактически тратит процессорное время. Вы не можете делать какие-либо аргументы, не измеряя вещи. В этот момент я считаю, что вы оптимизируете и тратите свое время. Не делайте ничего оптимизированного, если вы не можете измерить начальную точку и увидеть какие-либо улучшения в реальных числах.
Если ваше соединение с сигнальным слотом вызывается порядка 1000 раз в секунду, вы можете делать практически все, что захотите - накладные расходы не будут иметь значения. Это только начинает иметь значение, если вы находитесь в 100k invocations/second range, а затем, вероятно, вы ошибочно разрабатываете вещи.
Соединение сигнального слота без каких-либо параметров всегда быстрее, чем одно, которое отправляет некоторые параметры. Вы можете просто добавить свойство к объекту отправителя с помощью динамической системы свойств и проверить это свойство, используя sender()->property("..."). Динамический поиск свойств занимает немного больше времени, чем при использовании qobject_cast<...>(sender()), и вызов функции-члена в настраиваемом классе QObject или QWidget. Но это несущественно, потому что, если вы не можете измерить разницу, вам не нужно беспокоиться об этом. Преждевременная оптимизация - это действительно корень всего зла.
Вы правы: Мой ответ на большинство подобных вопросов также: «не оптимизируйте, если у вас действительно есть проблема и определенно знаете, что это причина». Однако мне было просто интересно, есть ли простой ответ, который заключается в реализации преобразователя сигналов или senderId, который очень дорог (с использованием RTTI и таблиц поиска или что-то в этом роде), которых следует избегать при часто называемых (> 1000 на scond). Но спасибо вам за подсказку с свойством, которое я мог бы проверить, если есть проблема. До тех пор я останусь с qsignalmapper и qobject_cast, который, похоже, работает. – TWE