Can I check the page fault time or something else.. :)
+3
A:
No question is stupid. If you're worried about memory fragmentation you will need to rework how you allocate memory so you can track it. Perhaps you should overload the new operator in those classes where you feel fragmentation would cause the most harm. Use some sort of logging functionality to write to you where it all is going. That should suffice as a first exercise. Then if you find that it really is harming you, you can create chunks of memory of the right size to guarantee your items are aligned in the manner you wish them to be.
wheaties
2010-02-03 14:31:33
Thanks. So that means for developing a stable large memory scale application, we must have my own memory management strategy, but not toy, and not give this work to default heap.
Buzz
2010-02-03 14:38:49
not exactly. What you should do is first ask yourself why you need this. Then, find out if it's really causing problems. Then, and only then, do you resort to rerigging those places where you need things non-fragmented. Don't pre-optimize code if it doesn't need it.
wheaties
2010-02-03 16:21:53
@Buzz: Don't do your own memory pools without a good reason, though. The heap itself works for most purposes, so I'd try it without first.
David Thornley
2010-02-03 16:22:54
+2
A:
If you are using C++, I wouldn't bother trying to predict it. The nice thing that encapsulation gives you is that you can at a later date change the memory allocation strategy without breaking all existing code. So I would do nothing and see if fragmentation does actually occur in real-life circumstances - it very probably won't.
anon
2010-02-03 14:40:35
A:
An indication of fragmentation would be for example, if your system reports having 5MB free but you are unable to allocate large chunks (like 1MB) at a time. This suggests that your system has some free memory but it has been chopped up into small non-contiguous pieces.
glutz78
2010-02-03 14:55:20
Checking something about page faults, as Buzz suggested, does the same thing.
David Thornley
2010-02-03 16:23:58
+2
A:
Are you on windows? There is a Low-fragmentation Heap available there that can be used as a preventative measure. It only takes a few lines to set up and should help with these issues.
You use HeapSetInformation to set it. Something like this should do the trick:
ULONG hi = 2;
HeapSetInformation(
(HANDLE)_get_heap_handle(),
HeapCompatibilityInformation,
&hi, sizeof(hi));
Matt Price
2010-02-03 16:01:31
By default, if you identify via the manifest file that you're Vista/Win7 compatible and you don't start the process with the debugger, you'll get the LFH heap
Paul Betts
2010-02-04 01:51:59
Interesting I didn't know that. We're using this on an application that is running on Windows Server 2003. When we move to the newest server will this apply?
Matt Price
2010-02-04 15:40:21
+1
A:
AFAIK memory fragmentation is likely to happen when there is a lot of allocation and deallocation of small objects.
Have a look at Boost.Pool to prevent memory fragmentation.
http://www.boost.org/doc/libs/1_41_0/libs/pool/doc/index.html
Fair Dinkum Thinkum
2010-02-03 16:49:15
A:
Your mem fragmentation is largely due to the data structures you use and your memory manager. You can usually assume any lib you want to use will have lots of memory fragmentation. To completely stop it you need to use data structures that minimize these issues and try to avoid allocating and deallocating data uneccessarily and possibly tackle memory manager itself.
Charles Eli Cheese
2010-02-04 00:48:21