Вещи искать в Вашем коде

Если Вы не уверены, где начать искать потенциал, фиксирует к Вашему связанному с файлом коду, вот некоторые подсказки относительно того, где начать смотреть.

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

• Ищите места, где Вы используете более старые вызовы файловой системы. Большинство Ваших вызовов должно использовать интерфейсы Objective C или основанные на блоке интерфейсы. Вы можете использовать вызовы уровня BSD также, но не должны использовать более старые Основанные на углероде функции, воздействующие на FSRef или FSSpec структуры данных. XCode генерирует предупреждения, когда он обнаруживает Ваш код с помощью устаревших методов и функций, поэтому удостоверьтесь, что Вы проверяете те предупреждения.

• Ищите места, где Вы используете функции обратного вызова или методы для обработки данных файла. Если более новый API доступен, который берет блочный объект, Вы могли бы хотеть обновить свой код для использования того API вместо этого.

• Ищите места, где Вы выполняете много маленьких операций чтения или операций записи на том же файле. Можно ли собрать в группу те операции и выполнить ли их одновременно? Для того же объема данных, одной большой операции чтения или операции записи обычно более эффективно, чем много маленьких операций.

Используйте современные интерфейсы файловой системы

При решении, который подпрограммы вызвать, выберите, позволяющие Вам указать использование путей NSURL объекты по тем, которые указывают пути с помощью строк. Большинство ОСНОВАННЫХ НА URL подпрограмм было представлено в OS X v10.6 и позже и было разработано с начала использовать в своих интересах технологии как Центральная Отгрузка. Это дает Вашему коду прямое преимущество на многожильных компьютерах, не требуя, чтобы Вы выполнили много работы.

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

Общие советы

Что следует, некоторые основные рекомендации для сокращения действия I/O Вашей программы. Они могут помочь улучшить Вашу связанную с файловой системой производительность, но как со всеми подсказками, убедиться измериться прежде и после так, чтобы можно было проверить любое увеличение производительности.

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

• Объекты контуров повторного использования. Если Вы не торопитесь для создания NSURL для файла повторное использование, которые возражают так, как Вы можете, а не создавать его каждый раз, Вам нужен он. Определение местоположения файлов и создание URLs или информации о пути занимают время и могут быть дорогими. Многократное использование объектов, создаваемых из тех операций, экономит время и минимизирует взаимодействия Вашего приложения с файловой системой.

• Выберите надлежащий размер буфера чтения. При чтении данных с диска на локальный буфер размер буфера, который Вы выбираете, может иметь сильное воздействие на скорости работы. Если Вы работаете с относительно большими файлами, это не целесообразно выделять буфер 1K, чтобы считать и обработать данные в маленьких блоках. Вместо этого создайте более крупный буфер (скажите 128K 256K в размере), и читайте очень или все данные в память прежде, чем обработать его. Те же правила запрашивают запись данных к диску: Запишите данные так последовательно, как Вы можете с помощью единственного вызова файловой системы.

• Считайте данные последовательно вместо того, чтобы перейти вокруг в файле. Ядро прозрачно кластеризирует операции I/O, который делает последовательные чтения намного быстрее.

• Избегите перескакивать в пустом файле перед писанием данных. Системе, возможно, придется записать, обнуляет в прошедшее пространство для устранения разрыва. Вы должны всегда иметь серьезное основание для включения «дыр» в Ваших файлах во время записи и должны знать, что выполнение так могло бы подвергнуться потере производительности. Для получения дополнительной информации посмотрите, Заполняют нулями Задержки, Обеспечивают Безопасность по Стоимости.

• Задержите операции I/O, пока для Вашего приложения не будут нужны данные. Золотое правило того, чтобы быть ленивым применяется к производительности диска, а также многим другим типам производительности.

• Не злоупотребляйте предпочтительной системой. Используйте предпочтительную систему для получения только пользовательских настроек (таких как положения окна, настройки представления, и пользователь обеспечил предпочтения), и не данные, которые могут быть недорого повторно вычислены. Перевычисления простых значений значительно быстрее, чем чтение того же значения от диска.

• Не предполагайте, что кэширование файлов в памяти ускорит Ваше приложение. Кэширование файлов в памяти увеличивает использование памяти, которое может уменьшить производительность другими способами. Плюс, система может кэшировать некоторые данные файла для Вас автоматически, так создание Ваших собственных кэшей могло бы сделать вещи еще хуже; посмотрите, что Система Имеет свой Собственный Механизм Кэширования файлов.