Не существует удовлетворительного обобщенного ответа, является ли синглтон быстрее, чем несколько экземпляров.
Я поговорю об общих экземплярах (не синглетонах).
Вы можете сделать некоторые обобщения более высокого уровняс общими экземплярами.
Если у вашего объекта нет изменяемого или критического состояния потока, то вы можете уменьшить количество создаваемых объектов, предоставив общий доступ к этому экземпляру.В этом случае вы сократите количество создаваемых вами объектов (неизвестно, должно ли это быть проблемой в вашем конкретном случае).
Аналогичным образом, если вы обнаружили проблему, вы часто можете пересмотреть дизайн класса, чтобыповторно использовать и делиться соответствующим образом для проблемы, которую вы наблюдали.Это часто состояло бы в разделении изменчивого состояния большого класса и его неизменного состояния и разделении неизменных частей между транзакциями.Этот метод часто используется для решения более сложных проблем и может встречаться несколько раз в довольно сложном приложении для iPhone, но это не часто проблема, которую люди считают достойной исправления в небольших приложениях, так как разработчик не считает эту проблему стоящей своего времени.
Если ваши объекты находятся в состоянии или должны работать в поточно-ориентированном режиме, то вы можете соответствующим образом пересмотреть то, что необходимо совместно использовать, а что нет необходимости совместно использовать.Это также сильно зависит от того, как выполняется ваша программа.
Итак, допустим, у нас есть:
- один общий экземпляр, который форматирует даты для вас
- и чтообъект имеет некоторое внутреннее изменяемое состояние, в котором он содержит временные результаты (не обязательно хороший дизайн, но ...).
Поможет ли общий экземпляр?
По сравнению скаждый раз создавать новый экземпляр? Да.Вы бы создали гораздо меньше временных объектов.Это может стоить больше, чем само вычисление.
В сильно многопоточном контексте со многими датами для преобразования по сравнению с одним экземпляром на поток? Нет. Вам нужно заблокировать, иклиенты из всех потоков будут конкурировать за один и тот же ресурс.Ваша программа была бы быстрее, если бы она не была многопоточной.Хорошим (общим) решением в этом случае было бы создание одного экземпляра форматера на поток для обработки всех этих дат, устраняя необходимость блокировать форматер во время обработки каждой даты.
Вопрос высокого уровня в OPне имеет правильного ответа без контекста.Вы также должны хорошо понимать свою программу и свою проблему и выбирать правильный подход к проблеме.Проблема (или отсутствие конкретной) не должна служить оправданием для создания синглтона.
В общем, я бы сказал, что сначала вам следует сосредоточиться на хорошем дизайне, но также помнить о выполнении вашей программы.проблемы и учиться у них.Многие разработчики, которые ждут, пока не возникнет заметная проблема с производительностью, не распознают (и, соответственно, учатся) свои прошлые ошибки.Таким образом, это помогает время от времени заходить и профилировать ваше приложение, а также узнавать, как улучшить те проблемы, которые возникают, даже если нет «очевидной проблемы с производительностью».Плохо построенные конструкции также имеют так много проблем с производительностью, что отношение сигнал / шум образца / профиля не будет очень полезным - будет гораздо меньше, чем очевидных проблем, и многие из них могут быть трудно исправить после этого.Профилируя и изучая, как писать оптимизированные программы, вы будете заранее знать о соображениях производительности и избегать и распознавать их в следующий раз, когда будете писать программу.Также потребуется меньше времени для распознавания проблем, которые возникнут в будущем.