CoreFoundation против Фонда

Question

При разработке iPhone скорость имеет решающее значение.Кто-нибудь знает, есть ли разница в скорости между использованием типа CoreFoundation (например, CFMutableDictionaryRef) и типа Foundation (его аналога NSMutableDictionary).

Я думаю, что манипулирование типом CF будет быстрее, поскольку ему не нужно разбрасывать сообщения времени выполнения ObjC. Является ли это необоснованным предположением, кто-нибудь действительно изучал это?

Answer 1

В техническом смысле да, это быстрее, именно по этой причине.

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

На iPhone экономия может быть больше, но это по-прежнему самый маленький прирост скорости, который вы можете получить.Гораздо лучше потратить время на профилирование вашего приложения в Инструментах, на работу там, где оно вам скажет, и на устранение проблем в вашем собственном коде.

И именно здесь Foundation становится быстрее: Твой время.

Код, который использует функцию автоматического освобождения Foundation, когда это возможно, экономит вам много времени и избавляет от головной боли, избегая легко предотвращаемых утечек памяти (а именно, забывчивости записи или невозможности доступа к памяти). release Сообщения).CF не имеет автоматического выпуска, поэтому вам нужно явно указать CFRelease все, что вы создаете или копируете с его помощью, и когда вы забываете или не можете получить доступ к этому коду (я имею в виду когда— Говорю по опыту), вы потратите гораздо больше времени на поиск утечки памяти.Статический анализатор помогает, но он никогда не сможет уловить все.

(Вы технически может autorelease CF-объектов, но код для этого ужасно уродлив, и вы лишь снижаете и без того незначительный прирост скорости.)

Итак, придерживайтесь Foundation как можно дольше.Не переусердствуйте с автоматическим выпуском;даже в чистом Cocoa все еще бывают случаи, когда явное освобождение объектов оправдано (в основном тесные циклы), и это вдвойне актуально для Cocoa Touch (поскольку iOS уничтожит ваше приложение, если вы выделите слишком много памяти, поэтому вам захочется высвободить большой объем памяти). объекты, такие как изображения, как можно скорее).Но обычно автоматический выпуск экономит гораздо больше времени, чем CF когда-либо сэкономит вашим пользователям.

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

Answer 2

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

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

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