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=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.129.69.21 with SMTP id s21mr11653460ywa.66.1497864148218;
        Mon, 19 Jun 2017 02:22:28 -0700 (PDT)
X-Received: by 10.157.52.232 with SMTP id t37mr686306otd.15.1497864148180;
 Mon, 19 Jun 2017 02:22:28 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!1.eu.feeder.erje.net!feeder.erje.net!2.us.feeder.erje.net!newspeer1.nac.net!border2.nntp.dca1.giganews.com!nntp.giganews.com!s24no1024987qte.0!news-out.google.com!s132ni5353itb.0!nntp.google.com!f20no1696977itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 19 Jun 2017 02:22:27 -0700 (PDT)
In-Reply-To: <oheej5$jru$1@gioia.aioe.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=92.103.99.138;
 posting-account=GmLOCAoAAABtDjDYQ4FbF8OEbF1VMKeh
NNTP-Posting-Host: 92.103.99.138
References: <c00a464f-5587-4a8e-a11a-589f7030127a@googlegroups.com>
 <cde3f44b-95b5-44d5-89ec-790f429f4e63@googlegroups.com>
 <oheej5$jru$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4c2990e4-b1aa-4784-86d0-d7cfe4844e1d@googlegroups.com>
Subject: Re: GNAT.Sockets Streaming inefficiency
From: masterglob@gmail.com
Injection-Date: Mon, 19 Jun 2017 09:22:28 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:47004
Date: 2017-06-19T02:22:27-07:00
List-Id: <comp.lang.ada>

Le vendredi 9 juin 2017 17:24:24 UTC+2, Dmitry A. Kazakov a =C3=A9crit=C2=
=A0:
> On 2017-06-09 15:30, gautier_niouzes@hotmail.com wrote:
>=20
> > It could be related to a performance bottleneck in 'Read and 'Write,
> > perhaps more than to the nature of the stream (socket vs. file vs. ...)=
.
>=20
> 1. Without NODELAY. Writes are buffered and spilled out either when the=
=20
> buffer is full or when the coalescing algorithm timeout expired. With=20
> string length is not a multiply of the buffer and moderate output rate=20
> or synchronized output, the last frame carrying the string will be=20
> always delayed. So the observed latency will be more or less the=20
> coalescing algorithm timeout.
>=20
> 2. With NODELAY. Individual writes are sent in independent frames. If=20
> 'Output or 'Write write individual characters separately, plus the=20
> string bounds, then the network gets flooded with short frames and the=20
> latency depends on how good the stack, the OS, the network=20
> infrastructure are.
>=20
> In either scenario there is nothing good to expect.
>=20
> --=20
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I currently do not use "NO_DELAY", but the thing is that the "producer" pro=
cess is 100%. This tends to indicate that it is not this kind of issue (I w=
ould have long execution time, but not a 100% CPU usage).

I have to try other implementations proposed (like using something else tha=
n Stream 'write & 'Read)