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

Сначало выдаёт в список все запрошенные юсером файлы
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 секунды
но конечно не с начала где лежат все заголовки