example

char str[51]="01234567890123456789012345678901234567890123456789"; LPVOID* a=GlobalAlloc(GPTR,1000000); for(DWORD i=0;i<1000000;i++) { a[i]=GlobalAlloc(GPTR,51) memcpy(a[i],str,50) } for(DWORD i=0;i<1000000;i++) GlobalFree(a[i]);

In this code, I measured a tick account for the first cycle, 2500 is spent and on the second one 120,000.

  • Based on the name, I would not expect speed from this feature. (And by the way, why not malloc or new ?) - VladD
  • so historically :) now began to optimize a very old prog found this brake place. already measured with strings everything will come out much faster. But maybe there is an option to speed up what is, without rework. My head just doesn’t fit why to select and fill up works 50 times faster than just to release - slayertmb
  • 2
    GlobalAlloc / GlobalFree actually makes system queries. And they are "expensive". The fact that you think that GlobalFree should be faster is far from a fact. The correct approach is to allocate memory in one piece, not hundreds of small ones. - KoVadim
  • ... What, in fact, makes the runtime. Then the received piece is distributed in parts to those who cause malloc . - VladD
  • pieces may vary incl. by lenght. And this, I have already found how to optimize (string), is rather a theoretical question why this happens. Maybe the option in the compiler settings is what it is. Or remake to Local ..... Virtual ... probably not worth it because it consumes a lot of memory - slayertmb

1 answer 1

History reference:

https://stackoverflow.com/questions/34326835/localalloc-vs-globalalloc-vs-malloc-vs-new translation: http://www.transl-gunsmoker.ru/2009/10/localalloc-globalalloc.html

In short, in bearded times there was a segmental memory, global and local heaps, selectors and near and far pointers. Then (with the release of Win 9x, and later NT) switched to a "flat" model of memory, the separation of pointers to selectors, near and far pointers has sunk into summer, but backward compatibility has remained.

The present is described here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa366533(v=vs.85).aspx

And the present says that modern operating systems do not provide a division into global and local heaps, as a result of which the Global and Local function groups are the same and choosing between them is a matter of personal preference (unless of course you write under Win16). Moreover, the transition from a segmental memory model to a virtual one made some of the functions meaningless (since there are no more selectors and near pointers).

In another article, https://msdn.microsoft.com/en-us/library/windows/desktop/aa366596(v=vs.85).aspx, it says that the objects that are allocated for memory through the GlobalAlloc or LocalAlloc functions are located on private, fixed pages of memory with read / write access, but not available for other processes. It also mentions that the size of the allocated physical memory can be MORE than the requested one, and the GlobalSize and LocalSize functions should be used to determine the actual allocated size. In addition, there is also written about the huge overhead of the Global and Local functions, so their use in the modern world is highly discouraged (in the case of development for an appropriate platform).

As for the speed of the work of freeing memory, then the question is complex and ambiguous, because what the OS kernel does when calling GlobalFree is known only to Hindus, this kernel is written by.

If you made measurements in debug and msvc, then you need to set _NO_DEBUG_HEAP = 1 in the environment settings of the studio, since Debug uses a completely different implementation of memory allocation for debugging.