В Objective-c, где лучше определить переменную с точки зрения производительности?

Question

Где лучшее место, чтобы определить локальные переменные (которые повторно) в реализации:

1. Внутри кода (есть возможность объявить его везде) - например, внутри оператора цикла.
2. В начале блока реализации.
3. Как глобальный для переменной класса внутри {} после @implementation myclass.

ЗАМЕЧАНИЕ: Я полагаю, что это дубликат, но я не уверен, что является лучшим. Вопросы, которые я нашел, - это @interface vs @implementation разделы.

Answer 1

1. Внутри кода (есть возможность объявить его везде) - например, внутри оператора цикла.
2. В начале блока реализации.

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

Как правило, большинство программистов ObjC имеют тенденцию объявлять переменные в той точке, в которой они впервые используются. Это помогает вам не забывать удалить эту переменную при удалении кода, который ее использует, и значительно упрощает некоторые виды рефакторинга. Пожилые программисты C иногда помещают все переменные в верхней части функции, но это привычка от тех дней, когда это требовалось компиляторам C. (Некоторые по-прежнему считают, что включение всех переменных в верхнюю часть улучшает читаемость, но это определенно не показатель производительности.)

3. Как глобальный для переменной класса внутри {} после @implementation myclass ,

Это зависит от того, требуется ли вам распределение или нет. Как правило, это будет усложнять оптимизатор. Но если вы можете повторно использовать объект, не перераспределяя его, это может быть намного быстрее. Это полностью зависит от вашей программы. Конечно, было бы ужасной практикой делать это регулярно «потому что это быстрее». Во многих случаях это будет медленнее, потому что это помешает оптимизатору.

Эти виды микрооптимизации, как правило, лучше всего подходят для оптимизатора. Он может (и делает) реструктурировать ваш код для повышения производительности. Вместо того, чтобы сосредоточиться на этом, сосредоточьтесь на том, чтобы убедиться, что фрагмент кода, который вы оптимизируете, называется реже. Изменение алгоритма O (n^2) в алгоритме O (n) полностью затмит любые улучшения, которые вы получаете по видам изменений, которые вы описываете.