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!news2.google.com!news1.google.com!news.glorb.com!newsfeed-0.progon.net!progon.net!news.germany.com!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.de!t-online.de!news.t-online.com!not-for-mail From: Stefan Bellon Newsgroups: comp.lang.ada Subject: Re: Finding out minimal allocation unit Date: Fri, 06 Apr 2007 10:06:52 +0200 Organization: University of Stuttgart Message-ID: <4ecf314352sbellon@sbellon.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.t-online.com 1175847019 00 25774 aULC6kKr7T4vS4Kq 070406 08:10:19 X-Complaints-To: usenet-abuse@t-online.de X-ID: Tl--fmZXgehhAdcyCwhnh6S8l8A2PtfVqtWwLh6SJ+GEL9TD2E+h4c User-Agent: Pluto/3.04c (RISC-OS/5.11) NewsHound/v1.50-32 X-Request-PGP: http://www.sbellon.de/gpg.asc X-PGP-ID: 05360CB9 / 55DB 48FE BA59 7BA0 2B9D 4822 38C5 EC21 0536 0CB9 X-URL: http://www.sbellon.de/ Xref: g2news1.google.com comp.lang.ada:14808 Date: 2007-04-06T10:06:52+02:00 List-Id: Randy Brukardt wrote: > 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.) Ok, will have a close look at storage pools. > 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. Just an example, in one case of our tools, I replaced the simple linked list with the above mentioned "b-list" and memory usage went down from 2500 MB zu 1900 MB. That's a saving of 600 MB. So, yes, we are concerned about efficiency in memory storage as we come close to the 3 GB limit of addressable user space on 32-bit machines. > 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. Will do. Thanks for all the help and ideas! -- Stefan Bellon