MD5 и SHA-1 хэши массивных файлов - PullRequest
1 голос
/ 06 октября 2011

РЕШЕНО - Я использовал комбинацию ручного управления (в обход сборщика мусора) и сопоставленной опции NSData. Оказывается, iStat не обладал нужной памятью, а инструменты указывали на ожидаемое поведение. Кроме того, вызовы CC_MD5 () и CC_SHA1 () действительно уже вызывают CC_MD5_Update () и CC_SHA1_Update (), поэтому они также не вызывают проблем.

В настоящее время я работаю над приложением Какао, которое должно хэшировать массивные файлы, используя SHA-1 и MD5. Я использую CC_MD5 и CC_SHA1 и читаю в файле объект NSData. Однако при этом используется огромное количество оперативной памяти и по какой-то причине происходит утечка памяти, например, через сито, даже несмотря на то, что на объект NSData не ссылаются… Я подозреваю, что сборщик мусора изо всех сил пытается не отставать.

Какой самый лучший (самый простой, если возможно, также возможный, но я не склонен выполнять какую-то дополнительную работу для ускорения процесса) способ выполнения хэшей MD5 и SHA-1 для таких больших файлов, как этот?

Follow-Up

Как упомянуто ниже, сопоставленные NSData могут помочь, но я думаю, что нашел другой вариант. Это все еще требует некоторой работы, но кажется более надежным решением. Идея состоит в том, чтобы использовать NSFileHandle и читать «чанки» - так, может быть, максимум 256 МБ за раз. Затем (например, для MD5) используйте CC_MD5 (), а затем серию CC_MD5_Update () для вычисления хэша в чанках. Объединение этого с ручным управлением памятью должно помочь.

1 Ответ

3 голосов
/ 06 октября 2011

Вы используете файлы с отображением в памяти? Таким образом, вам не нужно считывать весь файл в память, а ОС позаботится о кешировании необходимого:

[NSData dataWithContentsOfFile:@"filename.dat" 
                       options:NSDataReadingMappedIfSafe 
                         error:&error];

(вы также можете использовать NSDataReadingMappedAlways для принудительного отображения памяти)

...