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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,56525db28240414a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.107.167 with SMTP id hd7mr434947wib.0.1343316226723; Thu, 26 Jul 2012 08:23:46 -0700 (PDT) Received: by 10.66.78.233 with SMTP id e9mr1403518pax.35.1343316104170; Thu, 26 Jul 2012 08:21:44 -0700 (PDT) Path: q11ni71877290wiw.1!nntp.google.com!16no16170285wil.1!news-out.google.com!p10ni65039764pbh.1!nntp.google.com!border1.nntp.dca.giganews.com!novia!volia.net!news2.volia.net!feed-A.news.volia.net!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsfeed.straub-nv.de!news.swapon.de!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Keean Schupke Newsgroups: comp.lang.ada Subject: Re: Efficient Sequential Access to Arrays Date: Sat, 21 Jul 2012 09:14:11 -0700 (PDT) Organization: http://groups.google.com Message-ID: <37aca7fe-e367-4a37-8d8b-babd75f264d1@googlegroups.com> References: <9d4d4463-4c7e-40f4-a167-933eb056c6a5@googlegroups.com> <5007ecf3$0$9507$9b4e6d93@newsspool1.arcor-online.net> <3dbfa883-54c8-4269-a567-26dde8ead4cd@googlegroups.com> <72dbbd45-320b-436a-9d81-fcb6d02504e1@googlegroups.com> <500a9811$0$6639$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: 82.44.19.199 Mime-Version: 1.0 X-Trace: posting.google.com 1342887365 5333 127.0.0.1 (21 Jul 2012 16:16:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 21 Jul 2012 16:16:05 +0000 (UTC) In-Reply-To: <500a9811$0$6639$9b4e6d93@newsspool2.arcor-online.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.44.19.199; posting-account=T5Z2vAoAAAB8ExE3yV3f56dVATtEMNcM User-Agent: G2/1.0 X-Original-Bytes: 3299 Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-07-21T09:14:11-07:00 List-Id: On Saturday, 21 July 2012 12:52:48 UTC+1, Georg Bauhaus wrote: > On 21.07.12 10:24, Keean Schupke wrote: > > Ignoring performance which is the best way to structure this? Is there another way I have missed? > > If returning had meant a copy anyway, a copying procedure > seems another option. Okay, but not suitable for large values if we care about performance. > > Also, are there cases where some callback style interface would do? > That is, pass an "algorithm" to the containing structure for > computation much like the Process parameter of Query_Element, > or like when GUI classes expect programmers to write a concrete > implementation of some abstract type that specifies the protocol. Here are my results: 24 byte nodes (all integers) : 42k sims per second 16 byte nodes (all short_ints) : 40k sims per second 32 byte nodes (all integers + padding) : 42k sims per second. So 32bit integers seem faster than 16bit integers, and as the whole data set fits in the cache (its less than 10kbytes) the size of the nodes does not really affect performance. I try something like query element next and see how that performs. Cheers, Keean. On Saturday, 21 July 2012 12:52:48 UTC+1, Georg Bauhaus wrote: > On 21.07.12 10:24, Keean Schupke wrote: > > Ignoring performance which is the best way to structure this? Is there another way I have missed? > > If returning had meant a copy anyway, a copying procedure > seems another option. > > Also, are there cases where some callback style interface would do? > That is, pass an "algorithm" to the containing structure for > computation much like the Process parameter of Query_Element, > or like when GUI classes expect programmers to write a concrete > implementation of some abstract type that specifies the protocol.