Re: Delphi memory manager.
nobody_at_noplace.not
Date: 07/20/04
- Next message: Bjørge Sæther: "Re: teaching a child - console or GUI"
- Previous message: B.r.K.o.N.j.A.: "Re: Messages..."
- In reply to: Martin Harvey (Demon Account): "Re: Delphi memory manager."
- Next in thread: Martin Harvey (Demon Account): "Re: Delphi memory manager."
- Reply: Martin Harvey (Demon Account): "Re: Delphi memory manager."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 20 Jul 2004 09:09:01 -0400
On Mon, 19 Jul 2004 23:25:05 GMT, "Martin Harvey (Demon Account)"
<martin@_nospam_pergolesi.demon.co.uk> wrote:
>I reckon I can guess what it is. I bet the Delphi memory manager
>synchronises via something that internally is represented as a
>dispatcher object, whereas the other memory managers probably use
>interlocked operations, or a spinlock.
>From the header of Delphi's default memory manager (getmem.inc)...
>{ *********************************************************************** }
>{ }
>{ Delphi Runtime Library }
>{ }
>{ Copyright (c) 1996,2001 Borland Software Corporation }
>{ }
>{ *********************************************************************** }
>
>// Three layers:
>// - Address space administration
>// - Committed space administration
>// - Suballocator
>//
>// Helper module: administrating block descriptors
>//
It's just soaking up a whole lot of time doing stuff that windows heap
manager already does anyway.
Consider the case of deallocating a whole series of pointers...
Delphi comes in with it's memory manager, using virtual memory allocation
routines, frees the memory, launches into a cleanup operation, destroys is't
allocated blocks, updates the allocations database then notifies the
suballocator and helper module the memory is freed. Right behind this
windows does exactly the same thing in response to VirtualFree and
GlobalFree making everything happen at least twice.
Allocation is even more embarrassing since in order to use virtual allocate
you must first call global allocate to reserve space. Delphi adds a big
chunk of overhead into this by building virtual memory allocations within
the globally reserved chunk, then performing memory blocking to track the
sub-allocation... in essence duplicating window's heapalloc and heapfree
calls... then windows has to do it all over again when virtual and global
allocation calls are made.
In essence Borland is trying to second guess Windows native memory
management and it's not working out so well. It ends up being bloated and
slow, just like their SEH functions are (same programmer?).
Memory management at the language level can generally be reduced to a small
handful of calls:
HeapCreate -- get a memory handle for your application
HeapAlloc -- create variable space within your heap chunk
HeapFree -- release memory back to the windows heap
HeapReAlloc -- increase or decrease memory allocated to a variable
HeapCompact -- housecleaning routine to consolidate gaps in memory
HeapDestroy -- destroy memory handle and surrender memory to windows
These functions internally do everything Borland's Memory Manager does...
and leaves the overhead of blocking and deblocking etc. to windows. Nicely
enough, the Heap* calls will generate exceptions if problems occur.
If you call HeapCompact after each HeapFree call you end up with a fully
self maintaining memory system. ... and the memory management routines only
get called once.
-----
Laura
- Next message: Bjørge Sæther: "Re: teaching a child - console or GUI"
- Previous message: B.r.K.o.N.j.A.: "Re: Messages..."
- In reply to: Martin Harvey (Demon Account): "Re: Delphi memory manager."
- Next in thread: Martin Harvey (Demon Account): "Re: Delphi memory manager."
- Reply: Martin Harvey (Demon Account): "Re: Delphi memory manager."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|