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,81633e7277ffacee X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada containers and custom allocators Date: Sat, 12 Jan 2008 10:59:28 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <472f2c87-1238-42a5-8b94-92e9b70981da@f47g2000hsd.googlegroups.com> <2d464e2f-b043-4d45-8abd-ca392e92b4f3@i29g2000prf.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1200153568 1620 192.74.137.71 (12 Jan 2008 15:59:28 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 12 Jan 2008 15:59:28 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:JdvNwjgTt77OGH4uITXtdNzrMpI= Xref: g2news1.google.com comp.lang.ada:19351 Date: 2008-01-12T10:59:28-05:00 List-Id: Maciej Sobczak writes: > On 11 Sty, 23:41, Robert A Duff wrote: > >> Why does it give spectacular performance improvements? >> Doesn't this indicate that the default storage management >> is needlessly inefficient? > > Default storage management is always needlessly inefficient, because > it is general and cannot benefit from any additional knowledge about > what will be allocated. Every single bit of additional knowledge is an > improvement opportunity in some area. Fixed-size allocators can use > faster algorithms than general allocators. True, but the container implementation knows whether it is allocating fixed-size objects. > Another axis of improvement with custom allocators is thread-safety. Good point. I'd like to have a language where the compiler can tell which objects are shared by more than one thread. But that's not Ada (nor is it C++). > The global allocator cannot assume anything about threading and has to > be defensive in relation to threads, which means that it has to > proactively synchronize everything, always - just in case. You don't necessarily have to lock every allocation and deallocation. There are more efficient schemes, but you're right -- there is a cost. - Bob