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: a07f3367d7,3a6a9f1d654285ba X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!inka.de!rz.uni-karlsruhe.de!news.belwue.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 01 Sep 2009 13:34:17 +0200 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada Shootout program for K-Nucleotide (patches) References: <4a743343$0$32674$9b4e6d93@newsspool2.arcor-online.net> <0c18b36c-7af0-454c-8208-9b0416111a1f@w41g2000yqb.googlegroups.com> <4a758ce2$0$31338$9b4e6d93@newsspool4.arcor-online.net> <4a967b33$0$32671$9b4e6d93@newsspool2.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4a9d06b9$0$30234$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 01 Sep 2009 13:34:17 CEST NNTP-Posting-Host: 4ea552e4.newsspool1.arcor-online.net X-Trace: DXC=in:916`EA^Bgj[ZPFj7ehOic==]BZ:afN4Fo<]lROoRA^YC2XCjHcbIo[ Ole-Hjalmar Kristensen schrieb: > astra06:~/ada/div-ada> uname -a > SunOS astra06 5.10 Generic_137137-09 sun4u sparc SUNW,Sun-Fire-V440 > astra06:~/ada/div-ada> ls -l x.txt > -rw------- 1 ok145024 clustra 60000000 Sep 1 12:03 x.txt > astra06:~/ada/div-ada> time ./get_line_test < x.txt > 0.49u 0.09s 0:00.59 98.3% > Comparing the two programs, they are on a par, almost exactly. However, yours is IMHO less messy. It also has return Copy & Get_Line; which, I guess, solves the problem of long lines, even at the expense of copying. Can we reduce the copying overhead? The copying would be have O(f(Item'Length)) with f(n) ~= s*(s+1)/2 where s = n/BUFSIZ, so it is in O(n**2). We could, I think, use a storage pool: - whenever copying is needed, allocate another buffer right next to the current buffer. Use the newly allocated buffer for the recursive call. - on reaching of line/file, reinterpret the sequence of buffers in the storage pool as a String. Finally, Free. Can this be done? (This won't make a Shootout program any smaller, but seems good for the general case...)