Reduce write()s for builtins

[faho]

Description

Our io_streams_t is, when it comes to pipes (including the terminal), an extremely thin wrapper over write(2).

Whenever you do streams.out.append() or streams.out.push_back() that corresponds to one write(2). This means doing something like

for (wchar_t c : somestring) {
    streams.out.push_back(c);
}

is extremely slow. The pattern we see a lot is

streams.out.append(somestring);
streams.out.push_back(L'\n');

So, this PR tries to reduce how often we do that, sometimes by constructing strings on-the-fly like

streams.out.append(somestring + L"\n");

Or doing some buffering.

I'd like to call out one egregious case, which is printf. This one would out.push_back for every character escape, so

printf (string repeat -n 200 \\x7f)%s\n (string repeat -n 2000 aaa\n)

would issue 400000 (four hundred thousand) write(2) calls. Now it has been reduced to 2000 (one per argument excluding the format string - I experimented with doing one big write but that turned out to be slower in some cases and would of course have worse latency and memory requirements). This used to take ~400ms, now it takes 16ms.

The rest of the wins are more modest, ranging from ~1.1x to 1.7x.

TODOs:

• [N/A] Changes to fish usage are reflected in user documentation/manpages.
• [N/A] Tests have been added for regressions fixed
• User-visible changes noted in CHANGELOG.rst

[mqudsi]

These changes look good and the wins are appreciable. I had a concern about excessive buffering but we already eschew builtins for cases where fish's internal pipeline buffering causes burdensome delays (such as using sed instead of string ... in some completions) so I don't think there's any risk of any long-running processes piping to/from builtins effectively becoming less usable if we increase buffering (and I think the additional buffering won't even matter in the cases where all output is buffered in one go, anyway).

[faho]

had a concern about excessive buffering but we already eschew builtins

For the most part, this is about "buffering" a line. That's hardly "excessive".

This is about instead of this:

write("completion");
write("\t");
write("description");
write("\n");

doing this:

string line = "completion" + "\t" + "description" + "\n";
write(line);

Additionally, this is about what happens when the builtin writes into a pipe - that means either to an external process or the terminal.

These will be changed:

string match "*" | command grep

printf %s\n foo bar baz

string repeat -n 5000 aaa

# Only the `string length` writes to an fd directly
string repeat -n 5000 aaa | string length

math 5 + 5 >/tmp/ten

These cases won't be:

string repeat -n 5000 aaa | while read -l foo; true; end

set -l fivethousandAs (string repeat -n 5000 A)

[ridiculousfish]

This looks fine to me, but it does impose some awkwardness on the builtins.

A more pleasant-to-use but complex alternative would be to support buffering directly in output_stream_t, example:

 {
      autobuffer_t buffer = streams.out.autobuffer();
      buffer.append(name);
      buffer.append('\n');
 }

and in buffer's destructor, it flushes its data to its origin stream, in one go.

Either that approach or what you've done here is fine with me, just wanted to toss that out as an alternative.

[faho]

A more pleasant-to-use but complex alternative would be to support buffering directly in output_stream_t, example:

I have thought about that, but it's not really any less effort if you want that line-buffering. Basically you would replace the streams.out.append(line) with buffer.flush() anyway.

I don't really want to buffer by length, because I'm imagining the latency characteristics might be weird? What if we have 490 bytes ready, we flush every 500 bytes and the next 10 bytes take a second because this is a super tricky regex match?

What would be possible would be a "append_line" that appends the \n itself, for simple cases. But even that's barely clearer than append(str + "\n")

[mqudsi]

Regarding a possible append_line(): it is/was my intention to add writev() support (where available) and expose that via a variadic append(...) and append_line() functions.