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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,229a77b902096176 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-11 07:11:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.vmunix.org!news-FFM2.ecrc.net!news.iks-jena.de!not-for-mail From: Lutz Donnerhacke Newsgroups: comp.lang.ada Subject: Re: fastest data structure Date: Wed, 11 Dec 2002 15:11:06 +0000 (UTC) Organization: IKS GmbH Jena Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1039619466 7148 217.17.192.37 (11 Dec 2002 15:11:06 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Wed, 11 Dec 2002 15:11:06 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Xref: archiver1.google.com comp.lang.ada:31694 Date: 2002-12-11T15:11:06+00:00 List-Id: * Etienne Baudin wrote: > The process is the same with the 3 test (always reading "un") , and the > running time seems depend on the record size....?? The increment can be done in a simple (incrementing by 4) or complex (increment by 17) way. Processors are optimized on special increments. The other way to compute the new address is even optimized on special offsets. Futhermore smaller records increases the data locality, so the cache does a better job on smaller data.