Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

сравнение 2-х TFileStream


Страницы:   1 2 3 4 5

Unknown1 ©   (2012-11-16 11:16:00) 

Как быстро сравнить?


QAZ9   (2012-11-17 17:11:00) [41]


> Если память процесса представляет собой решето

а в х64 типа решета не будет? :)


bems   (2012-11-17 13:15:00) [42]


> от если так делать, то отличия с поблочным чтением прямо
> из файлов с диска становятся не очень заметны. Наибольший
> выигрыш удалось получить, если CompareMem натравливать на
> целиком буфера. Но этот способ имеет недостатки.

может блоки слишком маленькие брались?


> Вообще со всем этим отображением на 32 бит системах проблем
> может быть больше чем кажется. Если память процесса представляет
> собой решето из занятых и свободных блоков, а это очень
> может получиться так, если в процессе работы он часто что-
> то будет отображать в память и параллельно выделять память
> для своих нужд, то спроецировать туда что-то значительное
> не выйдет

да, на х32 могут быть проблемы с размером, но х64 будет жить дольше


DVM   (2012-11-17 00:17:00) [43]


> bems ©   (16.11.12 21:08) [39]


>  или вызывать CompareMem поблочно, но при этом блоки не
> копировать лишний раз

Вот если так делать, то отличия с поблочным чтением прямо из файлов с диска становятся не очень заметны. Наибольший выигрыш удалось получить, если CompareMem натравливать на целиком буфера. Но этот способ имеет недостатки.

Вообще со всем этим отображением на 32 бит системах проблем может быть больше чем кажется. Если память процесса представляет собой решето из занятых и свободных блоков, а это очень может получиться так, если в процессе работы он часто что-то будет отображать в память и параллельно выделять память для своих нужд, то спроецировать туда что-то значительное не выйдет.


bems   (2012-11-16 21:08:00) [44]


> почему?
>
> Если файл большой, система скажет, что готово, отображено
> все. А потом, за кулисами, будет лазить в файл.
>
> против
>
> Зачитать в память все. Если не сбросит в своп - все в память.
>
в такой постановке они равны, а чтение в буффер не лучше


> Но тут надо учитывать, что сравнивать все равно придет поблочно
> читая из отображенных в память файлов, т.к. натравливать
> на них CompareMem не очень практично, т.к. при больших файлах
> этот процесс нельзя будет прервать и в реальной жизни так
> не удобно.

весь замапленный файл уже считай буффером и читать оттуда поблочно не придётся. А если нужно прервать то можно или или написать свою функцию сравнения, или вызывать CompareMem поблочно, но при этом блоки не копировать лишний раз


Inovet   (2012-11-16 20:45:00) [45]

> [37] QAZ9   (16.11.12 20:16)
> а вот функции меморимапеда даже некоректно переведены в
> самой дельфе (7й версии например)

Куда переведены заголовки что ли? И что, по этой причине запрещается пользоваться отображением файлов на память?


QAZ9   (2012-11-16 20:16:00) [46]


> обертки практически

ну как сказать :) иногда катастрофически ухудшают
лично я тестил с результатом в пользу буфера + у него есть некоторые плюсы которые с первого взгляда не бросаются в глаза
а вот функции меморимапеда даже некоректно переведены в самой дельфе (7й версии например)


DVM   (2012-11-16 18:17:00) [47]


> QAZ9   (16.11.12 17:31) [34]
>
> > DVM ©   (16.11.12 16:06) [26]
>
> нет, быстрей буфер если убрать всякие обертки аля "поток"

обертки практически не ухудшают результат, если не по одному байту читать


QAZ9   (2012-11-16 17:37:00) [48]

заодно дефрегментацию этих файлов сделай


QAZ9   (2012-11-16 17:31:00) [49]


> DVM ©   (16.11.12 16:06) [26]

нет, быстрей буфер если убрать всякие обертки аля "поток"
а чтобы без учета кэша тестить - перезагрузи комп :)


Игорь Шевченко   (2012-11-16 16:55:00) [50]

RWolf ©   (16.11.12 16:52) [32]

в 99% коллизий не наблюдается. В том числе и среди растровых изображений.


RWolf   (2012-11-16 16:52:00) [51]


> [31]

да я понял, что размер; просто попадаются наборы файлов одинакового размера — растровые изображения, иконки, карты и т.п., и вот на таких наборах можно поймать коллизию.


Игорь Шевченко   (2012-11-16 16:49:00) [52]

RWolf ©   (16.11.12 16:44) [30]

Ты невнимательно читаешь.


> считаю CRC и сравниваю его и размер. Если совпало, то в
> 99% файлы идентичны.


RWolf   (2012-11-16 16:44:00) [53]


> Это при 16-битном, не так ли ?


при 16-битном всё ещё хуже: 1/256.

http://ru.wikipedia.org/wiki/Парадокс_дней_рождения


Игорь Шевченко   (2012-11-16 16:42:00) [54]

RWolf ©   (16.11.12 16:15) [27]


> опасно при такой обработке полагаться на 32-битный CRC.


Как выяснилось - не опасно. К тому же я считаю 16-битный CRC


> есть приличный (1/65536) шанс ложного совпадения.


Это при 16-битном, не так ли ?


Leonid Troyanovsky   (2012-11-16 16:28:00) [55]


> Unknown1   (16.11.12 11:16)  

> Как быстро сравнить?

http://www.delphimaster.net/view/2-1187943014

--
Regards, LVT.


RWolf   (2012-11-16 16:15:00) [56]


> Я большие группы файлов обрабатываю с целью поиска идентичных.
>  Большие - десятки и сотни тысяч файлов.

опасно при такой обработке полагаться на 32-битный CRC.
есть приличный (1/65536) шанс ложного совпадения.
лучше какую-нибудь хэш-функцию из распространённых.


DVM   (2012-11-16 16:06:00) [57]


> Игорь Шевченко ©   (16.11.12 16:03) [25]


> Я большие группы файлов обрабатываю с целью поиска идентичных

ясно

Кстати я еще погонял тест на разных файлах, очень сильно влияет на результаты кэширование, т.е. фактически делать два раза тест на одних и тех же файлах уже бессмысленно. В среднем быстрее отображенные файлы, да.


Игорь Шевченко   (2012-11-16 16:03:00) [58]

DVM ©   (16.11.12 15:59) [24]


> А зачем считать CRC


Я большие группы файлов обрабатываю с целью поиска идентичных. Большие - десятки и сотни тысяч файлов.


DVM   (2012-11-16 15:59:00) [59]


> Игорь Шевченко ©   (16.11.12 15:50) [23]


> считаю CRC и сравниваю его и размер.

А зачем считать CRC если можно просто побайтно сравнить? CRC же тоже потребует прохода по всем байтам и ее вычислени заведомо медленнее, если речь именно о CRC, а не о Checksum. Имеет смысл, если только один файл многократно надо сравнивать с другими.


Игорь Шевченко   (2012-11-16 15:50:00) [60]

DVM ©   (16.11.12 15:42) [20]

В реальной жизни скорость сравнения двух файлов не так существенна, как кажется. Я делаю тупо, считаю CRC и сравниваю его и размер. Если совпало, то в 99% файлы идентичны.


Страницы:   1 2 3 4 5

Наверх

Титульная страница Поиск, карта сайта Написать письмо