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,ed3a51e96a1c868b X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Using local storage pools... Date: Thu, 24 Feb 2011 07:34:35 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <7elam6trrv39c3p9iop4fiduqa1jrat4r4@4ax.com> <87ipwawk3b.fsf@ludovic-brenta.org> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1298550875 16477 192.74.137.71 (24 Feb 2011 12:34:35 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 24 Feb 2011 12:34:35 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:9CYVzzGmWaRO9lB1e9RATMZNCSM= Xref: g2news2.google.com comp.lang.ada:18556 Date: 2011-02-24T07:34:35-05:00 List-Id: Brian Drummond writes: > I have been emailed privately, suggesting I report it to Adacore. Sorry. I emailed it by accident. I meant to post it here. Here it is: Brian Drummond writes: > Arguably they cheat : they do not explicitly free each tree node (the "free" > call has been deleted!) but free the entire pool at the end of the loop. > But if that's valid, Ada should be able to do the same. I don't think it's a "cheat". This technique is commonly used. I have used it in various compilers and static analysis tools and other programs. Whenever you have large numbers of small heap-allocated objects that all have roughly the same lifetime, this technique simplifies the program, makes it more efficient, and helps avoid dangling pointers. > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Some-Useful-Memory-Pools.html > suggests System.Pool_Local offers a way to do likewise - a pool that is > automatically reclaimed when it goes out of scope. Pool_Local is not what you want (for efficiency) in this case. What you want is a pool that allocates large chunks of memory, and allocates individual small objects within that, and deallocates the whole thing (all the chunks) at the end (Finalize). For efficiency, you never call Unchecked_Deallocation. I'm not sure if such a pool is part of gnatcoll, but if not, I'll probably add it to gnatcoll someday. Pool_Local would be more appropriate if the allocated objects are large (and usually have similar lifetimes). > This turns out to have its own performance problem, but that is another story... > > The question(or four) for now is ... should the following really raise > Storage_Error, i.e. am I doing something silly, and if so, what? > Or is this a bug in Gnat? I don't see anything wrong with your code. If you report it to AdaCore (report@adacore.com) it will get fixed (at low priority, if you're not a supported customer). I'm interested in storage pools -- maybe I'll be assigned to fix the bug (if it is a bug). - Bob