I did a global search on trunk\compiler and found the following numbers:
GetMem(): 212 hits
FillChar(): 362 hits
I haven't checked any other fpc folder, but I am sure those figures would multiply.
What I did notice was that GetMem() and FillChar() were being used in pairs most of the time --as opposed to using AllocMem() which had 16 hits.
My focus isn't on the merits of using AllocMem() instead of GetMem() and FillChar() pair; what I do notice is the fact that in a lot of places there is a strong need for zeroed memory.
That brings me to the idea of handling the zeroing of memory chunks by the memory manager (MM) instead of doing it in-line.
But, before getting grilled to death here, I floated this idea in forums.codegear.
Here it is:
nntp://forums.codegear.com/embarcadero.public.delphi.language.basm/848
[Quite a bit of the following text is taken from Thorsten Engler's replies to my and other's questions on the topic. For more detail please read the above NNTP thread]
The basic idea is this: In the memory manager a background (idle priority) thread/process does the zeroing --preferably using another core.
The idea isn't entirely new; Windows has been doing just that for over a decade (since Win98 and NT3.1). It is pre-zeroing pages in a background thread and making them available to applications through VirtualAlloc() calls.
In Windows, an idle priority background thread takes pages from the 'Free' list, zeroes them, and puts them into the 'Zeroed' list.
That way, when a new physical page is required, it can directly be taken from the 'Zeroed' list. Only if a new page is required and the 'Zeroed' list is empty is a page directly taken from the 'Free' list and zeroed JIT.
'Free' page count (which are pages that have been returned to the page pool, but which still contain whatever it is they contained before being freed) are always pretty close to 0, while the 'Zeroed' page count is usually much higher (except if the system is running out of physical memory).
This does not seem to have noticeable impact on Windows or else MS would have --I think-- given up on that long ago.
Now, back to the MM in FPC:
Obviously, zeroing is a waste of time for any allocation where it is not required. But all allocations for classes DO require it. And besides strings and dynamic arrays, classes a pretty much the major part of all allocations.
So, it seems, if we had something like what Windows has, we could get rid of all those GetMem() and FillChar() pairs and replace them with AllocMem() [and ReAllocZeroMem()] that retrieves pre-zeroed memory from the MM and increase the overall performance.
The worst case scenario would be this: MM doesn't have any 'Zeroed' memory. In which case, AllocMem() falls back to GetMem() and FillChar() pair.
Under Windows, MM could get intial zeroed memory through VirtualAlloc() to begin with and then zero only the returned memory.
I did try to lookup an equivalent to VirtualAlloc() and it seems calloc() is it --but I am not sure if it is, or whether it is available in all platforms.
Anyway, this is the idea.
I wonder what you think.
---------------
More hit data:
fpc/trunk/packages/
GetMem(): 1464 hits
FillChar(): 608 hits
trunk/lazarus/
GetMem(): 522 hits
FillChar(): 1366 hits