#shared mem (again)
2 messages in this thread
I contrived a test that measures process swap performance on all 3 versions of
MS Windows. And, here are the results, [for a i486DX-33, 16Mb mem, 256k
cache]:
process swaps per second
Windows 3.1: 1800
Windows/NT: 1200
Windows32s: 1200
Windows32s (dbg): 2.8 [due to DebugOutputString handling]
However, performance degrades substantially when I try to do memory copies
between two processes and a shared DLL. Under Win32s the performance
degrades as follows,
process swaps per seconds
CopyMemory(DLLdest, LocalSrc, 2048): 256
CopyMemory(DLLdest, LocalSrc, 1024): 230
memcpy(DLLdest, LocalSrc, 2048): 254
byte-by-byte FOR loop of 2048 bytes: 190
At first I thought that the overhead was Win32s API overhead but the FOR
loop performance is worse than the API functions. Also the size of the
message doesn't make very much difference in swap rates. So, I now think
the performance hit is in sparse-virtual-memory validation which must be
activated on each process swap. Am I on the right track? If so, is there a
way to avoid doing this on every process swap? Would CreateFileMapping help
get around this?
Also, is there a similar performance hit if a DLL function accesses the
memory of an application rather than the other way around?
There is 1 Reply.
Something I want to make clear here: You are measuring the number of task
switched in Win32s (which depends on the rate at which each application
empties its message queue in turn) and when you are running memory copies it
slows this down – this makes sense to me. Am I missing something here? It
seems like almost any API usage would radically change the number of times
the current task is changed each second.
Lee