MD5 и SHA-1 хэши массивных файлов

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

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

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

Продолжение

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


objective-c md5 sha1 commoncrypto
person Justin Mrkva    schedule 06.10.2011    source источник
comment
Не могли бы вы опубликовать свой код о том, как вы это сделали? Спасибо!   -  person Parth    schedule 20.04.2018

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

person Tony Million    schedule 06.10.2011
comment
Я пробовал это, так как казалось, что это будет хорошее решение, но у него все еще есть неприятные утечки. Я работаю над тем, чтобы вернуться к ручному управлению (в обход сборщика мусора), поэтому я хочу посмотреть, помогает ли это в сочетании с явным освобождением. - person Justin Mrkva; 06.10.2011
comment
Также см. Мое продолжение выше о чтении файла по частям. Я собираюсь попробовать это в сочетании с ручным управлением памятью, а затем попробую сопоставить NSData поверх этого, чтобы увидеть, имеет ли это значение в этих условиях. - person Justin Mrkva; 06.10.2011
comment
Хорошо, я переключился на ручной режим, и сборщик мусора действительно был частью проблемы. Я снова попробовал сопоставленное чтение, и, судя по трассировке памяти в Instruments, он действительно не использует тот объем памяти, который, по мнению iStat Menus, он использует ... использование памяти никогда не превышает 10 МБ выделенной памяти в реальной памяти. Кроме того, я обнаружил, что CC_MD5 и CC_SHA1 оба вызывают CC_MD5_Update и CC_SHA1_Update, поэтому они тоже не вызывают проблем. Проблема решена! :) - person Justin Mrkva; 07.10.2011