From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,427e29f23a651ddb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder3.cambrium.nl!feeder1.cambrium.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Finding out minimal allocation unit Date: Thu, 5 Apr 2007 20:40:50 -0500 Organization: Jacob's private Usenet server Message-ID: References: <20070403144350.6c95e085@cube.tz.axivion.com> <1175606570.4684.11.camel@localhost> <461257ea$1@news.post.ch> <20070403153747.1c4f46ef@cube.tz.axivion.com> <4ecee347d7sbellon@sbellon.de> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1175823558 25305 69.95.181.76 (6 Apr 2007 01:39:18 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 6 Apr 2007 01:39:18 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news1.google.com comp.lang.ada:14802 Date: 2007-04-05T20:40:50-05:00 List-Id: "Stefan Bellon" wrote in message news:4ecee347d7sbellon@sbellon.de... > Markus E Leypold wrote: > > > And I thought it would exactly be the extra padding the OP was > > interested in? > > Yes, basically I'm interested in the padding which is inserted and > wasted and which could be used without resulting in a larger allocated > memory chunk. > > So, instead of doing: > > type Cell1; > > type List is access all Cell1; > > type Cell1 is record > Next : List; > Item : Item_Type; > end record; > > We would like to do: > > type Cell2 is record > Next : List; > Used : Natural; > Items : array (1 .. N) of Item_Type; > end record; > > Where N is chosen in a way that N is maximized without resulting in the > whole Cell to require the next larger allocation size. Right, but that obscures your algorithm and makes it harder to maintain. It's better to write a storage pool that does the blocking, and does it behind the scenes. (Of course, if the overhead of "Next" is contributing to the problem, you might not have any choice.) But, honestly, I don't see why you're so concerned about getting the blocking factor exactly right. Just make it big enough so you're always allocating at least 256 bytes at a time, and relax. Unless you have a huge number of these structures, the possible waste of a couple hundred bytes per list item isn't going to make much difference. And if they're expandable anyway, you're probably going to be filling them up. Remember, the actual OS memory allocator on Windows allocates in 64K chunks -- I doubt you want to use *that* size for blocking! So, in summary, if the insertion/deletion issues are really significant, then use a custom storage pool, and don't mess with the top-level algorithm. And if they're not, just allocate decent sized blocks and don't worry too much about the waste - it's inevitable unless you write your own storage pool (tuning as you are trying to do will only work on a single compiler version/target operating system version; any change to either is likely to change something - everyone is forever fiddling with their heap implementations to improve something or other). Randy.