CRC32-program

Metoden som du använder för att beräkna crc-summan är inte riktigt optimal. Det fungerar inte att allokera lika mycket minne som filen är stor!
Försök bara kolla crc på en fil som är typ 100mb så är det nästintill omöjligt.

Gör istället så att du jobbar med buffrar på säg 8192 bytes eller nått. Sedan gör du så att du läser 8192 bytes från filen kör crc på den, läser in ytterligare 8192 bytes osv osv.

Tycker du ska lösa det problemet omedelbart för som programmet är just nu går det tyvärr inte att använda.

Har inte testat det, bara kollat källkoden.

Precis som IcE säger så bör du läsa in en buffer åt gången. Det optimala är att använda 64 KB eller 128 KB stora buffrar, dvs samma buffer som windows använder internt (tror jag).

calcCRC32():
Här öppnar du filen med CreateFile(), för att sedan stänga den och öppna den igen med fopen() ?
Ett tips är att använda FILE_FLAG_SEQUENTIAL_SCAN istället för FILE_FLAG_RANDOM_ACCESS för att snabba upp inläsning.

compareCRC32():
Vore det inte bättre att jämföra DWORD-värden av CRC stället för att omvandla till en string och jämföra med strcmp()...?

Här är ett liten kodsnutt från ett program jag gjorde själv en gång i tiden:

#include <windows.h>
#include <tchar.h>

#define DO1(buf) crc = CRC32_TAB[((int)crc ^ (*buf++)) & 0xff] ^ (crc >> 8);
#define DO2(buf)  DO1(buf); DO1(buf);
#define DO4(buf)  DO2(buf); DO2(buf);
#define DO8(buf)  DO4(buf); DO4(buf);
#define DO16(buf) DO8(buf); DO8(buf);

#define CRC_BUFFER_SIZE_ (128*1024)

DWORD crc32_file(const _TCHAR * filename)
{
	DWORD crc = 0xFFFFFFFF;
	DWORD sizelow,sizehigh,dataread,len;
	HANDLE hFile;
	unsigned char *buf, *crcbuf;

	if((hFile=CreateFile(filename,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,
                         FILE_FLAG_SEQUENTIAL_SCAN,NULL)) != INVALID_HANDLE_VALUE)
	{
	    sizelow = GetFileSize(hFile,&sizehigh);
		if( !((sizelow == INVALID_FILE_SIZE) && (GetLastError() != NO_ERROR)) )
		{
			if( !(sizelow == 0 && sizehigh == 0) )
			{
				buf = (unsigned char *)malloc(CRC_BUFFER_SIZE_);
				do 
				{
					ReadFile(hFile,buf,CRC_BUFFER_SIZE_,&dataread,NULL);
					crcbuf = buf;
					len = dataread;
					while (len >= 16)
					{
						DO16(crcbuf);
						len -= 16;
					}
					if (len) do {
						DO1(crcbuf);
					} while (--len);

				} while(dataread==CRC_BUFFER_SIZE_);
				free(buf);
			}
		}
		CloseHandle(hFile);
	}
	return (~crc);
}

Jag har testat använda MemoryMapping men det visade sig vara en aning slöare än att göra som jag visade med koden ovan.

Om man MM:ar en fil och läser från den, kommer windows endast att läsa in data när det behövs, vilket innebär en del avbrott vid beräkningarna. och inte alls lika snabb "burst-rate".

MM används mycket vid spelprogrammering, där man behöver komma åt data i stora PAK-filer. Genom MM får man direkt åtkomst till fildatan i minnet, om den redan skulle ligga i Windows' filcache.

Annars om man skulle läsa in den från disk (som koden ovan) så måste Windows kopiera filens data från filcachen till programmets minne, vilket tar lite tid.

Sen ska MemoryMapping inte fungera så bra på Win9x men det kan man ju nästan bortse från.

Har gjort ett SFV-prog jag med. http://psionicist.online.fr/tSFV12.exe

Edit: C givetvis.

Mitt program ligger här. Kompilerad med unicode så den funkar nog bara i Win2K/XP.

Den kan endast kontrollera, dvs det går inte att skapa sfv med den. Klarar .sfv, .md5 och .par. Även SHA1/SHA2-summor skapade med fsum

Skrivet helt i C med WinAPI-anrop.

Snabbast borde vara att läsa nästa block medans man processerar ett annat. Asså, jobba asyncront.

Just nu jobbar programmet så här:

Read
Process
Read
Process
Read
Process
etc.

snabbare att göra:

task1 task2
Read  Idle
Read  Process
Read  Process
Read  Process
Read  Process
idle  Process

Det går att lösa utan trådar också faktiskt. Läsa ett block, starta en asyncron läsning och sedan processera. Sedan vänta på att asyncrona läsningen är klart och starta ny och sedan processera.

Eller så kan man lösa det med trådar fast det tror jag blir jobbigare.

EDIT: btw, tänk på när ni profilar att filecachen kan förstöra resultaten.

Finns en artikel här om crc32 och optimering.
http://www.codeproject.com/cpp/crc32.asp?target=crc

Han försökte göra med asyncront dock fick han det inte snabbare än syncront.