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 Newsgroups: comp.lang.ada Subject: Re: Finding out minimal allocation unit 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> <4ecf314352sbellon@sbellon.de> From: Markus E Leypold Organization: N/A Date: Fri, 06 Apr 2007 13:06:38 +0200 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:eCvnSENfvTOdeOowSGP/dLtdaIE= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.236.129 X-Trace: news.arcor-ip.de 1175857166 88.72.236.129 (6 Apr 2007 12:59:26 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:14826 Date: 2007-04-06T13:06:38+02:00 List-Id: Stefan Bellon writes: > 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. Since memory allocation patterns are usually not completely predictable, won't that mean, that (if don't allocated everything from custom storage pools) the maximum allocation will have a certain amount of statistical "jitter", i.e. will sometimes exceed the 3 GB limit and your application will fail now and then -- that is, the application will be anreliable? You would have to prove that 3GB is the absolute upper limit needed, something really difficult to do when you don't controll ALL allocation (as opposed to only this special list type). Regards -- Markus