Локальное создание переменной vs член класса

Use profiler Luke.

Есть ли смысл объявить их локально static

Не надо так делать в большинстве случаев.

Вообще прежде чем приступать к любой оптимизации, убедись, что ты оптимизируешь правильное место (как тут уже посоветовали, профайлером).

Конкретно cv::Mat стоит сделать членом, чтобы не аллоцировать память каждый раз при создании (если только ты не используешь внешние указатели при инициализации), но всё опять же зависит от конкретного случая.

Не надо так делать в большинстве случаев.

Почему нет?

чтобы не аллоцировать память каждый раз при создании

об этом я и говорю, но может компиляторы сейчас такие умные, что они и не выделяют память при каждом вызове. Мне не оптимизация интересна, а принятая практика и почему так.

Почему нет?

Потому что объект перестанет быть локальным по отношению к своему «родителю», а станет разделяемым между всеми вызовами конкретного метода (для всех инстансов). + Многопоточность. Жесточайший антипаттерн, в общем.

Само выделение памяти большой роли не сыграет, под локальный объект память будет выделена на стеке, что достаточно быстро, но затем будет вызван конструктор, и вот там уже может происходить много всего интересного. Просто возьми и проверь, написать простенький тест было бы быстрее, чем разводить всю эту возню на форуме

а принятая практика и почему так.

Общепринятая практика - это объявлять переменные наиболее локально к месту их использования. Так реализация алгоритма становится чище и незамутненней (меньше неясностей с зависимостью от глобального состояния).

Но в целях элементарной оптимизации некоторые «тяжелые» объекты лучше таки создавать один раз, как в общем случае с cv::Mat (при условии, что от вызова к вызову будут обрабатываться изображения одного типа/размера).

А если thread_local ?

Ты ведь ждал этого вопроса :P

Я, если честно, не знаток нового стандарта, и в основном пишу/мыслю по-старинке. Трэд_локал в данном случае лишь добавит ненужной сложности.

у меня (в жаве, на сайтах) картина обычно такая: кроме очевидных вещей типа алгоритмов поиска и ожидания io, нагрузка размазана примерно равномерно. Оптимизируй с любого места. (точнее, «оптимизуй не оптимизуй всё равно получишь »)

Ну почему же. Он решит проблему многопоточности и избавит класс от переменной-которая-нужна-в-одном-месте

Он не решит проблему разделения одной и той же переменной, нужной для конкретной задачи, разными инстансами объектов, решающих (возможно) разные задачи.

Это, конечно, верно.

Поэтому такой метод и применим лишь в очень ограниченном круге задач и для людей с бесконечной памятью, чтобы помнить об этом.

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

Есть ли смысл объявить их локально static, тогда на создание тоже не будут тратиться ресурсы при каждом вызове, ведь так?

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

Надо ли делать их членами класса, чтобы они создавались один раз при создании объекта класса или это будет микрооптимизацией?

а толку? что-то даже потенциальный профит неочевиден