GlobalAlloc & stralloc

[Mark Jones]

Hello, timings from an AMD XP 2500+ & Petrozski's new algo. These buffers are functionally equivalent, no?

Code Select Expand


stralloc 524288                        (18739 clocks)
invoke GlobalAlloc,GMEM_FIXED,524288   (11534 clocks)


[EduardoS]

Isn't the stralloc zeroed?

[zooba]

Heap functions are faster (MSDN says so :wink). GlobalAlloc and friends are (should be) only used for DDE, clipboard and OLE functions.

Code Select Expand

; P3M 1.4GHz 1024MB RAM
GetProcessHeap, HeapAlloc, HeapFree     (4973 clocks)
StringAlloc, StringFree                 (6725 clocks)

The StringAlloc and StringFree macros are from my ASM Runtime. They use a growable heap, which is initially smaller than 524288 bytes, and include advanced error handling for out-of-memory errors.

[Mark Jones]

Interesting how much faster this is on a P3 mobile! :lol

Code Select Expand


    db 32-(($-a) AND 31) dup (0CCh) ; ALIGN 32
misc1 PROC
    stralloc 524288
    strfree eax
    ret
misc1 ENDP

    db 32-(($-a) AND 31) dup (0CCh) ; ALIGN 32
misc2 PROC
    invoke GlobalAlloc,GMEM_FIXED,524288
    invoke GlobalFree,eax
    ret
misc2 ENDP

    db 32-(($-a) AND 31) dup (0CCh) ; ALIGN 32
misc3 PROC
LOCAL hProcHeap:DWORD
    invoke GetProcessHeap
    mov hProcHeap,eax
    invoke HeapAlloc,eax,HEAP_ZERO_MEMORY,524288
    invoke HeapFree,hProcHeap,0,eax
    ret
misc3 ENDP

    db 32-(($-a) AND 31) dup (0CCh) ; ALIGN 32
misc4 PROC
LOCAL hProcHeap:DWORD
nop
    invoke GetProcessHeap
    mov hProcHeap,eax
    invoke HeapAlloc,eax,0,524288
    invoke HeapFree,hProcHeap,0,eax
    ret
misc4 ENDP


misc1:     18839 (?)
misc2:     11703 (?)
misc3:     11859 (?)
misc4:     11791 (?)

Press enter to exit...

[zooba]

Clock Cycles (1): 6817
Clock Cycles (2): 5074
Clock Cycles (3): 4929
Clock Cycles (4): 4934

The 'stralloc' and 'strfree' macros (as defined in MACROS.ASM) use the OLE string functions, which are practically obsolete except when sharing between processes.

I'm impressed by only 15 cycles difference for zeroing heap memory, and this appears to be reasonably consistent as well.

Perhaps I have faster RAM in my laptop? Memory speed is always the bottleneck in these cases :U

[hutch--]

The OLE string memory functions have their virtue in what they are designed to do but as with any memory allocation function, there is a lot of latitude. As the major components of a dynamic string engine, their virtues are things like having a pre-allocated string pool which can be bashed ad infinitum without noticable memory fragmentation.

One of or members some time ago benchmarked a number of the commonly used memory allocation functions and the results were interesting. OLE string memory allocation is indeed slower than most of the rest but then its designed for a slightly different purpose. HeapAlloc() was a clear winner for high counts of small allocations and interestingly enough, the old GlobalAlloc() is a good performer on large allocations as long as the GMEM_FIXED flag is used with it.

The result at the time that was interesting was a memory allocation scheme designed by Ultrano. While it was slower that the others on regular sized block of aligned memory, it kicked ass on irregular sized blocks and it had the advantage of being subject to a low fragmentation level so Ultrano has done some good work here.