public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: Tee and file redirections are very slow to write anything.
Date: Wed, 24 Feb 2021 16:50:19 -0700	[thread overview]
Message-ID: <7bdae030-12c7-b2fa-9386-5e279382637d@SystematicSw.ab.ca> (raw)
In-Reply-To: <20210224224149.GM2979@dimstar.local.net>

On 2021-02-24 15:41, Duncan Roe wrote:
> On Wed, Feb 24, 2021 at 04:58:24PM -0500, Eliot Moss wrote:
>> On 2/24/2021 3:48 PM, ASSI wrote:
>>> Hamish McIntyre-Bhatty via Cygwin writes:
>>>> I found recently when trying to save output from a script for later
>>>> inspection that "tee" and file redirections seem to have massive
>>>> delays when run in Cygwin - usually nothing is written to file or
>>>> stdout until after the command has finished - not very helpful.
>>>
>>> You will want to switch from fully buffered to line-buffered or even
>>> unbuffered output.

>> And this does not have to do with Cygwin.  The same happens on Linux.
>> The default is that terminal I/O is unbuffered while other stream are
>> buffered.  Pipes come under "other streams".  One can make programmatic
>> changes to get around this, but most programs won't override the
>> default behavior on their own ...

> The (Linux) default is that terminal I/O is *line* buffered
> 
> The man page for tee doesn't show an option to change buffering, while that for
> grep does.

I believe the default for both Cygwin and Linux is 64KB pipe buffer, so if you 
want to see smaller chunks as they are generated, you need to add some utility 
that may allow you to change that e.g.

	$ tail -f access.log | stdbuf -oL cut -d ' ' -f1 | uniq

but read the disclaimers on the stdbuf and grep man pages, which is why it is 
not done more, especially under Cygwin where Windows adds its own performance 
penalties.
Some utilities may use read(2/3p), write(2/3p), or mmap(3) if they can and don't 
care about text or lines, for more efficient access to disk files, rather than 
buffered stream I/O functions.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

  parent reply	other threads:[~2021-02-24 23:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24 20:33 Hamish McIntyre-Bhatty
2021-02-24 20:48 ` ASSI
2021-02-24 20:59   ` Hamish McIntyre-Bhatty
2021-02-24 21:58   ` Eliot Moss
2021-02-24 22:41     ` Duncan Roe
2021-02-24 23:26       ` Takashi Yano
2021-02-25  3:54         ` Eliot Moss
2021-02-24 23:50       ` Brian Inglis [this message]
2021-02-25  7:50         ` Brian Inglis
2021-02-25  9:21           ` Hamish McIntyre-Bhatty
2021-02-25  9:51             ` Henry S. Thompson
2021-02-25 10:27               ` Takashi Yano
2021-04-18 18:45                 ` Hamish McIntyre-Bhatty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7bdae030-12c7-b2fa-9386-5e279382637d@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).