Quote:
I have a couple of ideas for increasing fphg's performance - particularly for realtime mode but I wanted to bounce them off you before I got too far with implementing my hacks. The inner loops are solid but we're not taking advantage of the fact that most active hands turn up in the same region time after time. I added some tables to track the 'active' regions and scan them on every loop - the inactive regions get scanned once every 5-50 loops depending on delay settings, with delay at zero, I'm scanning twice as many 'active' regions and still picking up new hands in new regions when they do occur.
The other thing I saw is that readprocessmemory is kinda slow - tracking regions means we don't have to do it every cycle, but virtualqueryex is an absolute dog. I haven't tried it yet but I think storing the MBI's, trying readprocessmemory and only doing the virtualquery when rpm fails will be much quicker. Combining these, we'll end up with another outer, outerloop of 1 - 2 seconds where all 'previous' regions are rpm'd and queried only if rpm fails, all regions are then scanned, but inside this loop we rpm and scan the 'active' regions - maybe 5 to 10 times and we have a much better chance of catching all the data.
I'm already tracking the regions but am not doing it in a 'nice' way and my C has been rusty for a decade. eg
unsigned int RegionStart[80];
Pls let me know if you think I'm off base or am about to hit a wall.
I just read my post preview and it seems the coffee has got to me, sorry if its completely unreadable. I hope I got the idea across though.
just added the following couple lines to prove that virtualqueryex doens't HAVE to be called immediately before readprocessmem - we can store the MBI's and MOST of the time the page boundaries won't move (they do move around when opening and closing tables but that happens in macro time)
void* NextAddress = SI.lpMinimumApplicationAddress;
NextAddress = (void*)((DWORD)MBI.BaseAddress + (DWORD)MBI.RegionSize );
MEMORY_BASIC_INFORMATION MBI2;
DWORD Ret2 = VirtualQueryEx(hProcess,NextAddress,&MBI2,size of(MEMORY_BASIC_INFORMATION));
Hey, just had a quick read through this and I think there is still alot of scope for optimizing FPHG.
The only things is that FPHG hand grabbing mechanism is going to be completely overhauled sometime over the next few weeks (likely within a month - I'm just about to move house, so can't really put the time in yet). Another 2+2er has already done all the groundwork and showed the new method works (and uses 0% CPU time with no missed hands).
It will mean all of the memory polling method will be gone, so it's prolly not worth putting in too much time fixing up the current FPHG code (you are welcome to if you want though, and just send me any code/patches and I'll post them as a beta).
I also think that FPHG needs a GUI, as when I first posted it I wasn't 100% sure how Party would take it (and assumed they would be less bothered by a simple looking CLI application). Well 8 months on and it seems prety much accepted byt Party and I think a GUI would now be a good idea to reduce the number of confused posting about how to add CLI args, etc.
Also, a FPHG FAQ is needed badly, as I seem to get 2/3 emails every few days saying basically "FPHG is saving the .hhf fine, but PT won't import them, can you help?". Ben has allready offered some space on hiw Wiki for this, but I just havn't had any time to get started on it...
Juk