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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 10 Aug 2009 20:17:21 +0200
From: Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>
Reply-To: rm.tsoh+bauhaus@maps.futureapps.de
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Benchmarking
References: <cbfd26ce-1c87-4606-8dd3-f413d2cbda89@n2g2000vba.googlegroups.com>
In-Reply-To: 
 <cbfd26ce-1c87-4606-8dd3-f413d2cbda89@n2g2000vba.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4a806430$0$31332$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 10 Aug 2009 20:17:20 CEST
NNTP-Posting-Host: bf27560f.newsspool4.arcor-online.net
X-Trace: 
 DXC=maQ9B^VhS5=D]ncZ]`hZ;14IUK<Cl32<14Fo<]lROoR1^YC2XCjHcb9F7X5D<7SGi:KQDKiQ7h<g>:E?]Iga\U24LDAIEM8NKU9
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:7671
Date: 2009-08-10T20:17:20+02:00
List-Id: <comp.lang.ada>

ravege wrote:
> I have a program that exports binary records to text format.  A sample
> record might be 196MB and the resulting export text file 607MB.  I've
> been using Text_Io to write out the text file, but inspired by the K-
> Nucleotide thread decided to give stream_io a try.  So now I want to
> compare.  I run the old Text_Io version and it takes 133 seconds to
> complete.  I run the Stream_Io version, it completes in 88 seconds!
> Nice improvement, I want to get some more test points so I run the old
> version again and get a 99 second time, okay... I run the new version
> and get a 145 second time to completion.  Is there some optimization I
> should be turning on/off, some OS caching I can configure so I can get
> less variation in my testing?

A dumb measure might be to write a fresh file that the
OS hasn't seen yet.  Otherwise, could it be possible to
formalize Yannick's observations into a testing strategy
that would measure either program in a loop, for a a few
hours or so?