0

I use Marshal.AllocHGlobal to allocate several huge chunks (100MB each) of unmanaged memory in my C# application (in Windows). I use these to allocate smaller pieces of unmanaged memory. After benchmarking these smaller allocations, I recognized that while over 99% of them cost 0-10 C# StopWatch ticks, some cost 30ms to 120ms and I could chase the cost down to individual memset calls (of 150 Bytes). I replaced the memset call with two memory writes to addresses in the memory area that memset would touch and observed the same cost. This means I have memory accesses that cost several 1000 times more than the cost of a main memory access. As page faults seem to have a similar cost, I was wondering if page faults could cause this behavior, but looking at the windows task manager, I am far from my main memory capacity when the problem occurs.

I tried to reproduce this in microbenchmarks without any success. Does anyone have any clue what could cause this behavior or what I could do to chase it down?

user1622959
  • 227
  • 3
  • 12
  • Sure, no reason to assume you are not just seeing the cost of a hard page fault that requires stealing RAM from another process. Lots of disk activity to backup the data in the RAM pages to the paging file. You can't benchmark it. Buy more RAM, an SSD is very nice. – Hans Passant Apr 11 '15 at 11:39
  • Don't benchmark with Task Manager! Use Performance Counters, you can tract the exact number and timing of any page faults of your program. – Scott Chamberlain Apr 11 '15 at 15:31
  • @Hans: Under what circumstance would a process steal RAM from anther process? Why would this happen when there is enough free physical memory available? I tried to recreate the allocations and some random memory accesses in a micro benchmark and the problem did not occur there. Scott: I do not use task manager for any benchmarking, but just to ensure that my application does not run out of physical memory. – user1622959 Apr 12 '15 at 08:24

0 Answers0