@samoth: thanks! I assume you don't have a small design document of your own, is your algorithm proprietary or do you have the code somewhere?

No design doc exists, if anything one would have to write the design doc after the implementation. Also, no publicly available sources exist at that time, sorry.

xor [edi],imm32 #7 cycles (imm-to-memory)
add edi,4 #2 cycles (imm-to-register)

OK; so assuming that this very inefficient code is not at all pipelined, that's 9 cylces (realistically it's more like 7). At a clock speed of, say, 2 GHz, that will be 211 MiB/s. That's little over 2 seconds to encode 500 MiB.

Plain C code will easily run that fast, and likely faster. Note that this kind of code (xor with single immediate) is exactly what a modern compiler will trivially vectorize (and most probably unroll 8 times), hiding pipeline stalls and being 100% memory bandwidth limited.

This is what my C compiler (gcc 4.7.1) produces for a simple [font=courier new,courier,monospace]for(...) x ^= immediate;[/font] loop without doing anything special:

L2:
.loc 1 122 0 discriminator 2
movdqa (%eax), %xmm0
pxor %xmm1, %xmm0
movdqa %xmm0, (%eax)
addl $16, %eax
cmpl %edx, %eax
jne L2

As for your stalling problem, reading or writing 64 MB to a hard-drive probably takes about 1 second, so likely your data is flushed to disk at that time. Since you say it occurs on the second read close after a write, I would guess that the system file cache is full and the OS decides to flush your recently written data to disk before reading in another 64 MB into the cache.

This example, for comparison, uses memory mapping (apologies for the very stripped down version of the MappedFile class, I would otherwise have had to include a lot more code with some dependencies -- the original has a few more features).
[source lang="cpp"]#include <windows.h>
#include <stdio.h>
#include <time.h>
#include <stdint.h>

class MappedFile
{
HANDLE file;
HANDLE mapping;
void* data;
uint32_t len;
unsigned int mode;

public:

enum map_mode_t { readwrite };
MappedFile(const char *name, map_mode_t map_mode = readwrite) : file(), mapping(), data(), len(), mode(map_mode) { Open(name, map_mode); }
~MappedFile(){ Close(); }

void Open(const char *name, map_mode_t map_mode = readwrite);
void Close();

void* Map(unsigned int map_size = 0);
void UnMap();

void* Data() const { return data; };
uint32_t Length() const { return len; };
};


void MappedFile::Open(const char *name, map_mode_t map_mode)
{
Close();
mode = map_mode;
int os_mode = GENERIC_READ | GENERIC_WRITE;
file = CreateFile(name, os_mode, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0);
len = GetFileSize(file, 0);
Map();
}

void MappedFile::Close()
{
UnMap();
CloseHandle(file);
file = 0;
}

void* MappedFile::Map(unsigned int map_size)
{
int os_mode = PAGE_READWRITE;
int os_mode2 = FILE_MAP_WRITE;
UnMap();
mapping = CreateFileMappingA(file, 0, os_mode, 0, map_size, 0);
data = MapViewOfFile(mapping, os_mode2, 0, 0, map_size);
return data;
}

void MappedFile::UnMap()
{
if(data)
{
UnmapViewOfFile(data);
CloseHandle(mapping);
data = 0;
}
}

int main()
{
printf("%u create mapping\n", time(0));
MappedFile f("test.dat");

if(!f.Data()) { puts("fail."); return 1; }

printf("len = %u (%u MiB)\n", f.Length(), f.Length()/(1024*1024));

printf("%u begin xor\n", time(0));

for(char* c = (char*) f.Data(); c < f.Data() + f.Length(); ++c)
*c ^= 'x';

printf("%u end xor, closing mapping\n", time(0));
f.Close();
printf("%u finished\n", time(0));

return 0;
}
[/source]

Compiled using Code::Blocks / MinGW-TDM 4.7.1-1, no special stuff, just pressing the "build" button, on a 7200rpm Samsung SATA-150 disk.

Output:

1352892208 create mapping
len = 546904331 (521 MiB)
1352892208 begin xor
1352892208 end xor, closing mapping
1352892208 finished
Process returned 0 (0x0) execution time : 0.891 s
Press any key to continue.

These timings show three things:
1. The Sysinternals Cacheset program is broken (I used this to clear the cache prior to the test)
2. The data is quite obviously fetched from the buffer cache.
3. Writing (or modifying) half a gigabyte worth of data does not "stall" (if the computer has sufficient RAM), just like I told you.

Numbers after rebooting (cache is certainly gone now):

1352893547 create mapping
len = 546904331 (521 MiB)
1352893547 begin xor
1352893557 end xor, closing mapping
1352893557 finished
Process returned 0 (0x0) execution time : 10.234 s
Press any key to continue.

This shows the following:
1. The disk stinks... 50 MiB/s, I really need to buy a new one some day (though I don't know whether it's fragmented)
2. Closing the mapping still takes "zero time", no stall visible for writing back the data.


EDIT:
Defraggler tells me that test.dat has 371 fragments, so maybe defragmenting would indeed have given a bit less of a "disk stinks" impression (considering that probably around 2 seconds are now being spent in seeking, which is 20%). Either way, it doesn't matter much for the result.

EDIT 2:
Well, wow... the gains from defragmenting are more like 50%.

1352894459 create mapping
len = 546904331 (521 MiB)
1352894459 begin xor
1352894464 end xor, closing mapping
1352894464 finished

Process returned 0 (0x0) execution time : 5.469 s
Press any key to continue.