Compare large files

Някой знае ли как могат да се сравнят 2 големи файла (примерно около 700 МБ)? Единия може да има сметнато нещо чрез хеш функция, обаче смятането не знам как трябва да става, за да работи бързо. а е важно да работи бързо. :)
Аз пробвах да сметна SHA512 на един 300 МБ файл и не можах да го дочакам. Е, верно че стойностите ги четах с FileStream, ама ако някой има велики идеи - нека сподели :). Благодаря ви предварително


Ние сме точици във вселената. А всеки човек е една цяла вселена...

смятането на хеш в твоя случай само забавя, защото първо трябва да се прочетат целите файлове, което е сравнително бавно и второ отива много време за изчислението.

най-добре почваш да ги четеш с ReadByte() само до първия различен байт и готово. така си спестяваш цялостното прочитане

на моя изчегъртан диск прочитането на 700 мб трае около 17 сек.

ако не е тайна за какво точно ти трябва да сравняваш така съдържанието на файлове, чисто любопитство

Едно добро решение за това е CRC (Cyclic Redundancy Check). Всички него ползват за сравняване на файлове: архиватори, клиент/сервъри, мрежовите протоколи, кракове ако щеш :) Абе най-вече като пращаш файл по мрежа и при получаването искаш да провериш дали не е прецакан. Аз го ползвах за едно клиент/сервърско приложение което работеше с файлове до 4GB.

Значи, ти трябва да си решиш какво трябва да ти е отношението скорост/сигурност. Примерно дали търсиш 100% сигурност че двата файла са еднакви или може да намалиш малко този процент за сметка на скоростта.

Аз лично направих следното: отварям файла, разделям го на 5, прочитам по 1 МВ от началото на първите 4 части и 1 МВ от крайа на файла, сглобявам ги в едно 5 МВ, и върху това правя CRC проверка.

Ама вероятност този подход да сбърка винаги има, тъй като примерно на 2 GB ти проверяваш едва 5 МВ. Затова ти казвам: ти си реши - скорост или сигурност. Или по-точно по колко от кое? Това е въпросът!





XM TurboCT .. where comfort meets power

Здрасти,

Това май ми е първи пост тук, та по-добре да се представя (с шефа на Соди се знаем, това е за другите). Ами накратко програмист съм с малко опит в .НЕТ и амбиции същия да става по-голям. Отскоро наблюдавам този клуб, досега върлувах предимно в Програмисти и PHP.

Въпроса ми е -- сигурно си пускал за проба CRC за целия 4 ГБ файл. Колко време вървя цялата работа? Аз съм си играл на PHP и Python с MD5 върху сравнително големи низове(от порядъка на няколко мегабайта) и всичко минаваше страшно бързо. Предполагам, че езика няма значение -- почти 100% сигурен съм, че и в двата случая съм викал компилиран MD5 модул, писан на чисто C.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Знам, че всеки го мързи да пробва и гледа да пита патилите. Мина ми през акъла, че не е хич трудно да пробвам и аз. Та хванах си колекцията филми на Джет Ли за опитно зайче ( 6.63 ГБ са ). Средата е Python на уиндоус ЕксПи на АМД Атлон на 2.5+ GHz (реални 1.8) със SATA HDD. Ето и резултатите:

>>> timer( sumAll )
started: Sun Apr 11 20:07:06 2004
Dragons of the Orient .avi : c9fc249f772bbbd56637c8483e7a7494
Iron Monkey.avi : 53f40931eb7aa1e65545e3174757fb91
Jet Li - High Risk.avi : ec2915c85fc3a0f8fb2354dce38307a7
Jet Li - Swordsman 2.avi : cc9232654183700cda9fe5326ba0a221
Jet Li - The defender.avi : acd1309a1c0a7beebc23b66441699e33
Jet Li - The Invincible Shaolin.avi : 9d3466807d6e86091ef44d3360f7bb2e
Jet Li - The Last Hero In China.avi : 319bd1a315ac3446d725e9f58baa7bde
Jet Li - The Legend of Fong Sai-Yuk II.avi : a8522e9dde536a81e890c6a2994b3481
Jet Li - The Legend of Fong Sai-Yuk.avi : c3b51984dc0d0a0b8aab5b550464476f
Jet Li - The master.avi : ddca082fb1ddbbf4092164274a5541aa
ended: Sun Apr 11 20:10:08 2004


грубо 3 мин. За 1 файл -- 684 МБ:

>>> timer( sumOne )
started: Sun Apr 11 20:16:17 2004
Dragons of the Orient .avi : c9fc249f772bbbd56637c8483e7a7494
ended: Sun Apr 11 20:16:35 2004

18 секунди.

Четенето от файла е глупаво направено -- ред по ред. Установих, че процесора не е зает максимално, явно има поле за оптимизации. Времето за CRC и MD5 беше еднакво (!!?!), което ме навежда на мисълта, че :
- тясното място е четенето от хард диска
- CRC32 и MD5 алгоритмите са с почти еднакво бързодействие?

Това последното е много интересно!

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

здрасти и добре дошъл в клуба
между другото и с мен се познаваш, макар и само от декемврийската сбирка на пхп клуба

тестът ти е интересен

надявам се клуба (и) в бъдеще да предлага интересни теми и "обмяна на опит и идеи"

Помня те от срещата, само дето забравих да спомена в предишния пост .

Иначе за сравнението, стана ми интересно и дори и да отнеме повече време от python пробата, довечера ще се пробвам с дотнет версия и ще опитам да подобря малко четенето. Естествено, ще квича тук ако има проблеми .

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Да не излезе Питон.НЕТ бре ?
Добре дошъл - доколкото това е "у нас"....

UB40 !

ami ideiata e kato se uploadva file da se proveri dali ve4e go nqma nqkade uploadnat (naprimer ako si vijdal v data.bg ponqkoga kak izkarva "edi si koi failove bqha iztriti i gi ima edi si kade")
neshto takova :) celta e faila da se save-ne samo ako go nqma ve4e
;)

Ние сме точици във вселената. А всеки човек е една цяла вселена...

еее ... дешев откога и ти на .нет

не съм пробвал такива тестове, щото на мене ми казаха < 1 сек ... да се оправам както мога

тия тестове са много относителни .... щото на различен хардуер нали се сещаш


XM TurboCT .. where comfort meets power

Поиграх си аз с System.Security.Cryptography.MD5CryptoServiceProvider. Постигнах абсолютно същите резултати като при питонското решение от миналия опит . Като дам на МД5 процесора директно файл стрийма и го оставя да си чете и смята хешовете отнася 18 сек за един филм. Точно като вчера. Реших да се направя на по-умен от класа и да си направя сам четенето от файла и да викам съответните методи за хеширане на блок и смятане на финалния хеш. Същата манджа. Експериментирах с различни размери на буфера за четене и само успях да увелича времето. Явно един файл от около 700 МБ при мен си се изчита от диска за 18 сек и това си е. За вдигане на самочувствието отделих четенето от смятането на хеша. Смятането на хеша, сигурно и с малко операции по виртуалната памет -- държа все пак 700 МБ в паметта, отне 3 сек. Самото четене пак си беше 18. Спирам експериментите.

Май и аз съм фен на решението на s_dimi за паралелно четене на парчета от файловете и директно изхвърляне при първата разлика. Може да се приложат разни по-умни методи за избиране на местата за четене, да речем първо проверка от началото и края. Май повечето файлови формати държат служебна информация с размери и [вече изчислени] хеш стойности в хедъра или футъра -- може би там шанса за различия е по-голям. Абе то и шанса два файла да са различни ако размера им е еднакъв ми се струва мижав.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

От доста време гледам хората ползват някакво чудо -- питон.нет, което не е чиста дотнет имплементация ами мостче, което позволява на питон кода да ползва дотнетнски класове. Отскоро се шуми и по питонските конференции се вихрят слайдове за чиста имплементация -- IronPython, ама не е рилийзната още.

Аз иначе се уча със C#, а предишния ми експеримент си беше с обикновен Python.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

В отговор на:

---

еее ... дешев откога и ти на .нет

---

Как бе!? И аз с мъжете .

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck