Делают ли накладные расходы метода target-c нецелесообразным подход к проектированию «множества маленьких методов»?

Я вообще предпочитаю использовать небольшие методы, как это рекомендовал Боб Мартин из Чистого кода . Я также прочитал достаточно о внутренностях Objective C, чтобы иметь хоть какое-то представление о том, как работает его отправка сообщений ( серия bbums особенно информативна в этом).

Несмотря на преждевременную оптимизацию, я хотел бы знать, является ли вся эта работа, которую Objective-c выполняет с objc_msgSend, с практической точки зрения достаточно значимой, чтобы подход «многих небольших методов» был нецелесообразным для проектов Objective-C.

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

осветление

Общий тон вопроса умышленный. Я не спрашиваю о настройке производительности конкретных приложений (именно поэтому я спрашиваю здесь, а не о SO), а больше о том, препятствуют ли языковые характеристики Objective-C определенному подходу к дизайну. Я заметил, что большая часть кода, который я видел от Apple и других сторон (на github и т. Д.), Имеет тенденцию к большим методам (и классам), и мне интересно, не является ли это предвзятостью, которая закралась из-за языка сам. Конечно, я, возможно, читал неправильный код, или это могут быть культурные, а не технические факторы, которые привели к тенденции, если она существует.

(Для чего это стоит, я сейчас пишу Objective-C и использую небольшие методы)

Дальнейший запрос

Я согласен с обоими ответами, которые были даны. Еще одна вещь, которую я хотел бы, чтобы кто-то указал мне на (надеюсь существенную) открытую (или иным образом видимую) кодовую базу Objective-C, которая использует хорошие короткие методы (и небольшие классы). Я еще не видел ничего в Objective-C, чтобы сравнить его (например) с источником фитнеса .

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

Но, как обычно, ваш пробег может отличаться ...

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

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

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