#iphone #objective-c #performance #oop #singleton
#iPhone #objective-c #Производительность #ооп #одноэлементный
Вопрос:
Это общий вопрос objective-c / iPhone:
Если у меня большой метод, лучше ли создать отдельный класс и вызывать метод из других классов или просто переписывать метод, когда он мне понадобится, в каждом новом классе? Я спрашиваю не с точки зрения чтения кода, а с точки зрения производительности iPhone. Заботит ли компилятор? У кого-нибудь есть доказательства того, что подклассы singleton выполняются значительно быстрее?
Комментарии:
1. Если у вас много объектов разных типов (т. Е. Не все подклассы одного и того же объекта), которые все должны выполнять один и тот же метод, у вас может возникнуть проблема с дизайном. Можете ли вы предоставить больше информации о том, что на самом деле делает этот метод?
2. Если у вас нет доказательств того, что существует заметная разница, вам даже не стоит начинать беспокоиться. Черт возьми, даже если есть заметная разница, вы не должны рассматривать ее для таких дизайнерских решений, если это не является доказуемым узким местом.
3. Похоже, вы имеете в виду не одноэлементный класс, а метод класса.
4. Ну, не беспокойтесь о производительности… беспокоитесь о семантике и структуре. Речь идет не только о чтении кода, но и о возможности повторного использования и ясности.
Ответ №1:
Спекулятивная оптимизация — это всегда преждевременная оптимизация. Если у вас проблемы с производительностью, создайте профиль и посмотрите, что происходит.
Переписывание методов в каждом новом классе вызывает ужасный запах кода, который говорит вам, что вы почти наверняка делаете это неправильно. И если уж на то пошло, если вы беспокоитесь о последствиях для производительности надлежащих методов объектно-ориентированного программирования, вам, вероятно, следует использовать что-то более низкого уровня.
(И чтобы сделать предположение о фактическом ответе на ваш вопрос: отправка метода Objective-C по-прежнему происходит независимо от того, где находится метод. Он невероятно оптимизирован, и вы, вероятно, не заметите никакой разницы.)
Комментарии:
1. Я спрашиваю, потому что я повторно использую метод, который выполняет запрос select из AWS. Очевидно, что структура этого метода каждый раз одинакова, но запросы имеют разные свойства / компоненты. Я мог бы создать класс, в котором есть только метод и свойства, и определять их каждый раз, когда мне это нужно, или просто выписать полный метод и определить каждое свойство с помощью локальной переменной. Учитывая это, все еще ли вероятна небольшая разница в производительности?
Ответ №2:
Нет удовлетворительного обобщенного ответа, быстрее ли одноэлементный класс, чем несколько экземпляров.
Я буду говорить об общих экземплярах (не одиночных).
Вы можете сделать некоторые обобщения более высокого уровня с общими экземплярами.
Если ваш объект не имеет изменяемого состояния или критического состояния потока, вы можете уменьшить количество создаваемых вами объектов, предоставив общий доступ к этому экземпляру. В этом случае вы уменьшите количество создаваемых вами объектов (должно ли это вызывать беспокойство в вашем конкретном случае, неизвестно).
Аналогичным образом, если вы обнаружили проблему, вы часто можете пересмотреть дизайн классов, чтобы повторно использовать их и предоставить общий доступ к ним для решения наблюдаемой вами проблемы. Это часто состояло бы в разделении изменяемого состояния большого класса от его неизменяемого состояния и распределении неизменяемых частей между транзакциями. Этот метод часто используется для более сложных задач и может встречаться несколько раз в умеренно сложном приложении для iPhone, но не часто является проблемой, которую люди считают достойной исправления в небольших приложениях, поскольку разработчик не счел, что это проблема, стоящая их времени.
Если ваши объекты имеют состояние или должны работать потокобезопасным образом, то вы можете соответствующим образом пересмотреть, что нужно использовать совместно, а что нет необходимости в совместном использовании. Это также сильно зависит от того, как выполняется ваша программа.
Итак, допустим, у нас есть:
- единый общий экземпляр, который форматирует даты для вас
- и что объект имеет некоторое внутреннее изменяемое состояние, в котором он содержит временные результаты (не обязательно хороший дизайн, но …).
Поможет ли общий экземпляр?
По сравнению с созданием нового экземпляра каждый раз?ДА. Вы бы создали гораздо меньше переходных объектов. Это может стоить дороже, чем само вычисление.
В сильно многопоточном контексте со многими датами для преобразования по сравнению с наличием одного экземпляра на поток?Нет. Вам нужно было бы заблокировать, и клиенты из всех потоков конкурировали бы за один и тот же ресурс. Ваша программа была бы быстрее, если бы не была многопоточной. Хорошим (общим) решением в этом случае было бы создать по одному экземпляру программы форматирования для каждого потока для обработки всех этих дат, устраняя необходимость блокировать программу форматирования во время обработки каждой даты.
Вопрос высокого уровня в OP не имеет правильного ответа без контекста. Вам также необходимо хорошо понимать свою программу и свою проблему и выбрать правильный подход к проблеме. Проблема (или отсутствие конкретной) не должна быть оправданием для создания одноэлементного.
В общем, я бы сказал, что в первую очередь вам следует сосредоточиться на хорошем дизайне, но также знать о проблемах выполнения вашей программы и извлекать из них уроки. Многие разработчики, которые ждут, пока не возникнет заметная проблема с производительностью, не осознают (и, следовательно, не извлекают уроков) из своих прошлых ошибок. Поэтому полезно время от времени заходить в приложение, профилировать его и узнавать, как устранить возникающие проблемы, даже если нет «очевидной проблемы с производительностью». У плохо сконструированных проектов также так много проблем с производительностью, что отношение сигнал / шум выборки / профиля будет не очень полезным — будет много менее очевидных проблем, и многие из них может быть трудно исправить постфактум. Профилируя и изучая, как писать оптимизированные программы, вы будете заранее знать о соображениях производительности, избегать и распознавать их при следующем написании программы. Также потребуется меньше времени для распознавания проблем, которые возникнут в будущем.