GlobalAlloc, GlobalFree, Malloc and friends

[hutch--]

Some of the later memory allocation strategies were designed to ease the usage for people who don't know how to manage memory properly. A big single allocation chopped up to suit the app is always faster than many messy small allocations. The OS is pretty good at handling it but if you understand what you are doing, you do it better yourself.

[frktons]

Hutch, in the future, if I'll know what I do much better,
I'll manage these stuff by myself.

For a 16 MB allocation HeapAlloc looks a little bit faster:

16.146  cycles for HeapAlloc
16.298  cycles for GlobalAlloc

16.190  cycles for HeapAlloc
16.741  cycles for GlobalAlloc

16.437  cycles for HeapAlloc
16.644  cycles for GlobalAlloc

16.062  cycles for HeapAlloc
16.732  cycles for GlobalAlloc


--- ok ---

So far I didn't find any concrete difference among the
various APIs used for allocating/freeing memory.
The Heap family seems to be reacher in options, but
for simple stuff they look almost the same.

[MichaelW]

A small example could help me to see the possibilities of this.

http://masm32.com/board/index.php?topic=508.msg3930#msg3930

[Greenhorn]

So far I didn't find any concrete difference among the
various APIs used for allocating/freeing memory.
The Heap family seems to be reacher in options, but
for simple stuff they look almost the same.

Global/LocalAlloc is just present for backward compatibility to 16bit. They are just wrapper and call HeapAlloc.
Global and Local Functions

For memory allocations up to 1MB HeapAlloc should be used. For allocations greater than 1MB VirtualAlloc should be used (which is called by HeapAlloc if size is more than 1MB).

Greenhorn

[dedndave]

i know the documents say that

then, i see certain operations that state that GlobalAlloc is required - lol
examples are reading from a resource or transfers to/from the clipboard (and some GDI+ stuff)

[frktons]

So far the use of HeapAlloc/Create/Free/Destroy... looks like the
solution that includes all the cases [less than 1MB / more than 1MB],
GlobalAlloc/LocalAlloc being just wrappers to call HeapAlloc, and
VirtualAlloc called by HeapAlloc when needed.

The test made by Michael [about alignment] says that , if you allocate
more than one buffer without freeing the previous ones, you can get
also a 8 byte alignment, not only 16 and its multiples.
::)

Win7, x64

290e80h
2937d0h
293fc0h

290e78h 8
2937c0h 64
293bb0h 16
293fa0h 32
294390h 16
294780h 128
294b70h 16
294f60h 32
295350h 16
295740h 64

295b40h 64
295f40h 64
296350h 16
296750h 16
296b60h 32
296f60h 32
297370h 16
297770h 16
297b80h 128
297f80h 128

2983c0h 64
2987c0h 64
298c00h 1024
299040h 64
299480h 128
2998c0h 64
299d00h 256
29a140h 64
29a580h 128
29a980h 128

[hutch--]

 

Contrary to popular opinion, GlobalAlloc() with the GMEM_FIXED flag calls the same function in NTDLL.DLL as many of the other memory allocation strategies and it has always been fast and it can allocate any amount of memory within physical limits and OS address range. While thge other strategies do the job, GlobalAlloc() is fast, flexible and can handle the limits while being easier to use.

[frktons]

Contrary to popular opinion, GlobalAlloc() with the GMEM_FIXED flag calls the same function in NTDLL.DLL as many of the other memory allocation strategies and it has always been fast and it can allocate any amount of memory within physical limits and OS address range. While thge other strategies do the job, GlobalAlloc() is fast, flexible and can handle the limits while being easier to use.

:t

[Tedd]

GlobalAlloc does call RltAllocateHeap, eventually... (after fiddling with the parameters and setting up.)
HeapAlloc is routed directly to RltAllocateHeap.

[frktons]

GlobalAlloc does call RltAllocateHeap, eventually... (after fiddling with the parameters and setting up.)
HeapAlloc is routed directly to RltAllocateHeap.

Yes Tedd, that's what they say.

[Tedd]

GlobalAlloc does call RltAllocateHeap, eventually... (after fiddling with the parameters and setting up.)
HeapAlloc is routed directly to RltAllocateHeap.

Yes Tedd, that's what they say.

Saying it doesn't make it true, but it's easily verified.

[frktons]

GlobalAlloc does call RltAllocateHeap, eventually... (after fiddling with the parameters and setting up.)
HeapAlloc is routed directly to RltAllocateHeap.

Yes Tedd, that's what they say.

Saying it doesn't make it true, but it's easily verified.

I mean it is what the official documentation says. And of course
it can be verified. :t

[Vortex]

Hi Jochen,

Did you test malloc exported by msvcrt.dll? How is the result?

[dedndave]

wouldn't msvcrt require some initialization ?
so hard to tell - lol

[Vortex]

wouldn't msvcrt require some initialization ?
so hard to tell - lol

Hi Dave,

No need for initialization :

Code Select Expand

include     \masm32\include\masm32rt.inc

BUFFER_SIZE = 64

.data

BuffSize    dd BUFFER_SIZE

.data?

pMem        dd ?

.code

start:

    invoke  crt_malloc,BUFFER_SIZE
    test    eax,eax
    jz      @f
    mov     pMem,eax

    invoke  GetComputerName,eax,ADDR BuffSize
    invoke  StdOut,pMem
    invoke  crt_free,pMem
@@:
    invoke  ExitProcess,0

END start


http://msdn.microsoft.com/en-us/library/aa246461(v=vs.60).aspx