Finding out minimal allocation unit
in [ADA]
|
From: Robert A Duff on 3 Apr 2007 09:48 Stefan Bellon <sbellon(a)sbellon.de> writes: > Is there a reliable way of finding out the smallest allocation unit? You could print out the addresses of allocated objects, and guess what's going on. If you have access to the source, you could read it. If the underlying allocator is malloc(), there will typically be a couple of words or so of extra space wasted per object, primarily due to design flaws in the C language. If you don't like that, then you can write your own allocator -- look up "storage pools". - Bob
From: Larry Kilgallen on 3 Apr 2007 10:12 In article <1175606570.4684.11.camel(a)localhost>, Georg Bauhaus <bauhaus(a)futureapps.de> writes: > On Tue, 2007-04-03 at 14:43 +0200, Stefan Bellon wrote: > >> Is there a reliable way of finding out the smallest allocation unit? > > FWIW, > > type LP is -- new ... with > record > forward: access LP; > backward: access LP; > end record; > for LP'Size use 63; > > should make the compiler complain when 63 bits aren't enough. Doesn't that deal with the size of an access variable, rather than the smallest allocation unit ?
From: Dmitry A. Kazakov on 3 Apr 2007 12:45 On Tue, 3 Apr 2007 14:43:50 +0200, Stefan Bellon wrote: > In a few places we are using long lists of items. Those items mostly > consist of just a pointer or a record of two pointers. We need cheap > insertions and deletions of elements in those lists, therefore we > indeed used linked lists and no array solution. If size is an issue, you can also use indices instead of access types. Provided that all items have same size. Then you split your list of records into lists of fields. type Index is mod ...; type Item_List is array (Index) of Item; pragma Pack (Item_List); type Previous is array (Index) of Index; pragma Pack (Previous); type Next is array (Index) of Index; pragma Pack (Next); First_Free : Index := ...; -- The list of free items (empty) First_In : Index := ...; -- The list (empty) Non_Yet_Visited : Index := ...; -- To avoid initialization of the list of free items You can avoid memory allocation in advance if you segment the arrays above and split Index into (Segment_No, In_Segment) pair. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Randy Brukardt on 3 Apr 2007 19:53 "Martin Krischik" <krischik(a)users.sourceforge.net> wrote in message news:461257ea$1(a)news.post.ch... .... > So I believe the OP wanted to know how to find out how much memory for > "new"ed object is allocated in total in order to know if extra > optimisation is needed. But that isn't really a meaningful question. It clearly depends on the storage pool, and if the storage pool comes from somewhere else, it may even depend on the OS version you are running. For instance, the standard storage pool in Janus/Ada uses a standard Windows heap. Those exhibit vastly different behavior on Windows 95 than Windows 2000, and somewhat different on almost every version of Windows. Rule of thumb: if the behavior of the standard storage pool actually makes a difference in your application, then don't use it! Write your own storage pool that has the behavior you need. It's relatively easy to do, especially if you have fixed size elements. And then you can effectively use an array to allocate elements and still have cheap insertion and deletion and reordering. Randy.
From: Markus E Leypold on 3 Apr 2007 11:17
Stefan Bellon <sbellon(a)sbellon.de> writes: > Martin Krischik wrote: > >> So I believe the OP wanted to know how to find out how much memory >> for "new"ed object is allocated in total in order to know if extra >> optimisation is needed. > > Exactly. :-) I'm only guessing, but here is my approach for GNAT: GNAT is AFAIK linked against libc (at least on Unix). On linux that is glibc, which provides methods to catch/trace malloc() requests. My suggestion is that you do that and look which sizes are actually requested from malloc(). Another option: Allocate objects in a loop and observe when sbrk() occurs. Regards -- Markus |