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,2caa964596702891 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!75g2000cwc.googlegroups.com!not-for-mail From: msimonides@power.com.pl Newsgroups: comp.lang.ada Subject: Re: Ada.Containers and Storage_Pools Date: 11 Aug 2006 11:22:24 -0700 Organization: http://groups.google.com Message-ID: <1155320544.504578.144080@75g2000cwc.googlegroups.com> References: <1155125040.715167.132300@m73g2000cwd.googlegroups.com> <44DA09B7.6010607@on2.com> <1155193272.902814.41240@i42g2000cwa.googlegroups.com> <44db3fb0$0$1013$39cecf19@news.twtelecom.net> NNTP-Posting-Host: 81.219.218.218 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1155320549 31809 127.0.0.1 (11 Aug 2006 18:22:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 11 Aug 2006 18:22:29 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Opera/8.54 (X11; Linux i686; U; en),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: 75g2000cwc.googlegroups.com; posting-host=81.219.218.218; posting-account=YHdqRw0AAAAIPYzcJprg4QGlRlBwcPu_ Xref: g2news2.google.com comp.lang.ada:6181 Date: 2006-08-11T11:22:24-07:00 List-Id: Matthew Heaney wrote: > msimonides@power.com.pl wrote: > > > > Having such a pool for use by containers' internal structures would > > enable us to choose more appropriate container types in terms of memory > > usage (eg. we had a list of data elements in resource records but now > > use vectors as they have less memory overhead on each element and are > > as good performance-wise when the number of nodes is small. But there > > is no (easy) way of measuring it). > > If you had a single-linked list, would you have used that instead of the > vector? I would consider it, for my application (1-3 elements usually, sometimes a dozen or so) it would probably use similar amount of memory as a vector and it would be possible to apply your previous suggestion. > > Yes, but this is only a partial solution. Adapting it to thousands of > > small vectors seems infeasible. > > Here's another idea. For the pool, you could use a container (say, a > list or map) of vectors, with the vector elements of the container > ordered by their capacity. If you need a vector, you would search the > container for a vector having the requisite capacity, and then use the > Move operation to move its internal array onto your vector object. > Would that work? In this case I would probably prefer to use a counter for objects in cache. On each insertion it would be increased, on removing - decreased. This would probably be faster, easier to implement and it would be trivial to check whether amount of free memory is below a threshold to trigger additional cleaning. It's basically the same idea that is used currently, but uglier - it would be implemented outside of a storage pool (where it in my opinion belongs). > > Ideally I could just specify the maximal size for all cache structures > > together and have the storage pool enforce it. > > The pool abstraction I describe above would only allow you to control > the memory for the vectors, not the total memory for maps and their > vector elements. But it might be good enough if the storage for the > elements stored in the vectors is large compared to the number of map > elements. It isn't required to be precise to fulfill it's basic purpose, which is preventing one module form using all available memory, so such solutions are viable. In fact such is the current state - by limiting the number of zone and data nodes, the size of the whole cache is limited, we just don't know what the limit is and how much it can vary based on data that is inserted. On the other hand it would be desirable to be able to tune maximal amount of memory assigned to each module of the program to let it make the most of it (and not use too much). It seems this would be easy if containers supported custom storage pools. Thank you for your suggestions and ideas. I will look into them once again when we start optimizing our program (all containers will be reviewed in the near future in order to choose best types, so now it is too soon for working on detailed solutions that you proposed). -- Marcin Simonides