Вобщем проблема следующая:
Программа для поиска и удаления дубликатов файлов и использует такой способ:

Сначало выдаёт в список все запрошенные юсером файлы
1. File1
2. File2
3. File3
4. File4
5. File5

выполняет сравнение таким вот образом


и получается 



всё прекрасно, но...
если в списке 5 файлов, то MyCompare будет выполняться 10 раз,
если в списке 10 файлов, то MyCompare будет выполняться 45 раз,
если в списке 100 файлов, то MyCompare будет выполняться 4950 раз,
если в списке 7000 файлов, то MyCompare будет выполняться 24 496 500 раз.
формула (Count*Count+Count)/2-Count.

MyCompare использует 2 потока Stream1 и Stream2, то есть получается, что на 7000 файлов функция будет обращаться 24 496 500*2 раз к открытию файлов.

В память загрузить тоже не получиться. т.к. при каждом сравнении например File1 и File2, File1 и File3, позиция с которой читается файл1 в масив постоянно разная она зависит от размера file2 или file3 (файла с которым сравниваем) 


для сравнения 7000 файлов получается примерно 10 часов  
как можно выполнить по другому не прибегая к такому невероятно огромному кол-ву открытия файлов или хотя бы выполнить этот процесс быстрее.

Дело в том что мне не просто нужно сравнить один файл с другим а у каждого файла сравнивается разная позиция и разным кол-вом байт
 
Результаты внушают=) через 10 часов=)

Или я чего-то не понял, но если файлы - разного размера, то зачем их сравнивать?

Можно попробовать сперва создать все FileStream и работать непосредственно с ними, а не с именами файлов.
Windows кеширует открытые файлы, поэтому повторный доступ к ним будет гораздо быстрее.
Правда, не знаю, как она отнесется к тысячам хендлов - где-то есть ограничение на их количество.

Можно убирать из списка файлы, которые признаны дубликатами. Цикл придется переделать на While или Repeat, но это не спасет, если нет дублирующихся файлов.

Тебе нужно сперва посчитать CRC каждого файла - это линейная операция O(n). А затем в своей функции MyCompare() сперва сравниваешь CRC файлов и если они сошлись, то только тогда проводишь дополнительную проверку на содержании внутри.

Понимаешь НАПРИМЕР может быть две одинаковых песни, разные размером, без заголовков, Остаётся метод BaitToBait. Если одна песня или картинка, или что то еще меньшее размером, то это не значит что файлы не одинаковые, тут ты мне скажешь наоборот, но в том то и фишка, что все подобные проекты, работают, так: если файл и файл2 размером не равны, то перейти к следующему, а тут совсем не так.




Тоесть типа 

не катит тут ты правильно сказал есть ограничение на кол-во
Выходит какая то ошибка что то вроде "недостаточно квот" по мойму
Пробовал но не помню точно.



Crc это вроде бы как контрольные суммы, точно про них не знаю, но вроде, если файлы разные размером, то и контрольные суммы тоже будут разными?

Есть пример программы вот

Это сообщение отредактировал(а) Antony41 - 26.4.2009, 23:10

1. В таком случае сохранять открытым хотя бы первый файл (т.е. File[i], переоткрывая только File[n]).
2. Взять AQTime (весьма полезная штука не только для этой задачи) и просмотреть, что же конкретно тормозит выполнение - открытие файла, чтение из него или сравнение. Где взять - не скажу, потому что сам взял не с официального источника 

Добавлено через 1 минуту и 21 секунду
А еще лучше было бы сохранять открытым не первый файл, а его уже считанный буфер (если это возможно, код пробежал по диагонали).

если позиция файла1 по соотношению к файлу2 была 5 000, и кол-во загружаемых байт 100 000, то если размер файла3 будет меньше, то и позиция файла1 при следующем чтении в поток будет другой.

получается,  остаётся вариант загрузить весь file1 в масив байт и сравнивать масив, тогда выолнение функции MyCompare станет быстрее в 2 раза, но только как загрузить весь файл в масив байт, а если это vob файл DVD фильма, и размер его 3,5-4,0 Гб.?

Такое не годиться? уже такое писал тебе...

Спасибо Christoph, именно с FilesAreEqual всё началось.
Но тут она не подходит

можно так на край)

Нельзя.
Тут дело не в размерности массива и не в связных списках (в этом плане гораздо лучше подойдут TList и TObjectList), а в количестве одновременно открытых хендлов. (хотя, опять-таки - я не нашел упоминания об ограничении на количество хендлов/файлов. Но это не значит, что его нет. По крайней мере - для GDI очень даже есть).

Спасибо Щас буду пробовать

Добавлено через 4 минуты и 56 секунд
Загрузить весь файл в один масив не получится, если он больше ОЗУ, наверное только потому.

ОЗУ тут ни при чем.
Адресное пространство, доступное процессу<>ОЗУ компьютера. Другое дело, что много выделишь - опухнет файл подкачки.

странная логика. на каком основании при побайтовом сравнении можно решить, что две "одинаковые" песни разного размера на самом деле одно и то же?!

сравнить их кусок а не весь файл

Добавлено через 53 секунды
но конечно не с начала где лежат все заголовки

Две песни. Допустим размер первой 5 мб, второй - 1 мб. Очевидно, что сравнивать по-байтово не имеет смысла. А вот если разница в размере - пару килобайт, то мб имеет:

Две идентичные песни. Разный битрейт. Без вариантов = )

Это сообщение отредактировал(а) Qu1nt - 30.4.2009, 17:53

обсолютно согласен! 

пока что наброски
у меня идёт проверка на размер и если  меньше 200 кб. 
А битрейт если разный, то это да вся структура меняется, остоётся только привести всё к одному битрету (Что займет много времени) или сравнить по заголовкам. но их может и не быть

или сравнивать "расжатые" из мп3 данные.

но не факт (точнее будет сказать ТОЧНО НЕТ) что расжатые данные с битрейта 32 и 196 будут одинаковы. да и сравнение таким способом затянется не на 10 часов а на 10 недель =), если совподений много. 
тему можно развить: есть кроме музыки ешчо и фильмы, картинки, архивы тож можно распоковать и проверить .... =)
имхо надо ешчораз подумать и может пользовать стандартный утиль comp.exe вызывать с нужными параметрами и ловить результаты ее работы.

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

так и сделал

Добавлено через 22 секунды
на 7000 файлов 3 часа

Неприлично много 
Пересматривай алгоритм в корне.
Исходи из того, что можно улучшить на порядок, как минимум.
IMHO, разумеется 

вот именно всё уже  что можно вырезал и ни чего больше не помогает! если сделать по другому алгоритм нарушается
вот код

конечно не знаю поймёте ли вы это=)

То, что ты привел - не алгоритм, а ф-ия сравнения двух файлов (если я правильно поняла).
Для получения общего представления о задаче еще нужно:
1. Как ты получаешь список файлов, которые нужно сравнивать
2. Как ты по нему пробегаешь, вызывая эту ф-ию сравнения
3. Словесная постановка задачи (грубо говоря: ТЗ), ибо мы видим
    только твою инерпритацию, которая может оказаться не самой оптимальной.

P.S.
 Я не обещаю, что посмотрю - уж очень загружена.
 Но даже если мне не удасться вырвать кусочек времени, то посмотрят другие
 и покажут "узкие места" твоей реализации.

P.P.S.
 Трудно говорить, не видя общей картины, но твоя ф-ия сравнения мне очень не понравилась 

Ты б расписал - какие сравнения тебе последовательно нужно провести.

Есть такая софтина Image Dupless ЕМНИП называется, сравнивает картинки. Качество ее работы само собой ОЧЕНЬ далеко от совершенства.

Есть ли вообще алгоритм позволяющий сравнивать хотя бы wav-файлы?