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-Thread: 103376,68494635acddb77e
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news2.google.com!news.glorb.com!feeder.erje.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: File output and buffering
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: 
 <60a35fd4-e5a6-4aa0-a73f-6815ce7e92fc@f36g2000hsa.googlegroups.com>
  <4af2f934-7458-4370-b325-c38e3a4068b8@s50g2000hsb.googlegroups.com>
 <b3f16c6a-742c-43c3-baec-9533db25e423@r66g2000hsg.googlegroups.com>
Date: Wed, 20 Aug 2008 11:21:48 +0200
Message-ID: <zygqo0yqaii4$.7mqs6h5m06we$.dlg@40tude.net>
NNTP-Posting-Date: 20 Aug 2008 11:21:49 CEST
NNTP-Posting-Host: f0a9e2c9.newsspool2.arcor-online.net
X-Trace: 
 DXC=KPPMh\RE`9D=8m7nZkdN^@A9EHlD;3YcB4Fo<]lROoRA4nDHegD_]REg2^T7L`icM@DNcfSJ;bb[EIRnRBaCd<MNJO1T0l3<0;LGM23k[le@PK
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:7397
Date: 2008-08-20T11:21:49+02:00
List-Id: <comp.lang.ada>

On Wed, 20 Aug 2008 01:59:52 -0700 (PDT), Maciej Sobczak wrote:

> On 20 Sie, 10:43, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> 
> Still valid question:
> 
>> 3. Why is buffered Ada.Text_IO as slow as non-buffered C's stdio? Who
>> is eating the 20x factor?

Because of page formatting, I suggest. You can use text streams instead.
[But don't use String'Write! Although, the newest GNAT optimized that,
AFAIK.]

BTW, buffering does not make I/O faster. It obviously does the opposite.
Certainly, you didn't mean the "last-mile" buffer held by the driver, which
is usually inaccessible. In some elder OSes you could directly write from a
user buffer mapped by the kernel, have record files etc. That was *fast*.
But then came C, Unix and Co., you know... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de