2009-08-09 3 views
0

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

Я использую ConnectionKit для обработки загрузки:

CKTransferRecord * record; 
record = [connection recursivelyUpload:@"/Users/me/large-folder" 
            to:@"/remote/directory"]; 

Это отлично работает для большинства файлов и папок. Хотя в этом случае @ "/ Users/me/large-folder" содержит более 300 файлов. Вызов этого метода запустит мой процессор до 100% в течение примерно 30 секунд, и мое приложение не отвечает (mac spinning ball). Через 30 секунд моя загрузка поставлена ​​в очередь и работает отлично, но это вряд ли идеально. Очевидно, что все, что перечисляет эти файлы, заставляет мое приложение блокироваться, пока оно не будет выполнено.

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

Любые идеи?

ответ

1

Использование акулы. Начните выборку, начните загрузку, и как только зависание закончится, прекратите выборку.

Если вывод подтверждает, что проблема заключается в ConnectionKit, у вас есть два варианта:

  1. Переключитесь на что-то другое.
  2. Внести исправление, из-за которого он не зависает.

Красота открытого источника заключается в том, что №2 возможно. Это то, что я рекомендую. Тогда у вас будет не только быстрый ConnectionKit, но после того, как сопровождающие согласятся с вашим патчем, все остальные, кто использует CK, тоже могут его использовать.

И если акула показывает, что проблема не в ConnectionKit (правило # 2 профилирования: вы будет удивляться), то у вас есть руководство акульего о том, как исправить приложение.

1

Поскольку проблема почти наверняка связана с перечислением, вам, вероятно, потребуется переместить перечисление в асинхронное действие. Скорее всего, они используют NSFileManager -enumeratorAtPath:. Если это основная проблема, то лучшее решение, скорее всего, переместит эту работу на собственный поток. Учитывая очень длительное время, я подозреваю, что они действительно читают файлы во время перечисления. Решение заключается в том, чтобы читать файлы лениво, прямо перед загрузкой.

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

Если вы блокируете только одно ядро ​​на 100%, я рекомендую установить Active Thread на «Main Thread» и установить Sample Perspective на «All Sample Counts». Если вы блокируете все свои ядра на 100%, я рекомендую установить Active Thread на «All Threads» и «Sample Perspective» на «Running Sample Times».

+0

Перемещение перечисления на собственную нить остановило программу от блокировки, однако я все еще работаю на 100% -ном CPU во время. Можете ли вы объяснить, что вы подразумеваете под «ленивым» чтением файлов? – nrj

+0

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

Смежные вопросы