Very slow file:write to stdout with latin1 encoding on OTP 26.2.3

[VLanvin]

Describe the bug
file:write/2 to erlang:group_leader() with latin1 encoding is unexpectedly slow on OTP 26.2.3. It is fine on OTP 26.0.2.

To Reproduce
Run the following script on OTP 26.2.3 with the input file (3MB) provided in this archive (redirect output to /dev/null).

main(_) ->
  Data = binary_to_term(element(2, file:read_file("input"))),
  io:setopts(erlang:group_leader(), [binary, {encoding, latin1}]),
  file:write(erlang:group_leader(), Data),
  ok.

time escript test.erl >> /dev/null takes ~1.6s. Commenting out the file:write or removing latin1 encoding reduces runtime to ~0.3s.

Expected behavior
file:write should be near-instantaneous there.

Affected versions
OTP 26.2.3
OTP 26.1.2
Doesn't happen on OTP 26.0.2

Additional context
This is a minimal repro of what happens in ELP's parse server.
The input file provided in the archive was obtained by running the parse server on OTP's unicode_util and dumping the resulting term.

[garazdawi]

I haven't checked, but I assume this is because with the new stdio implementation in 26 we keep all internal data as unicode. So the data is first converted from latin1 to unicode to then be converted back again before outputted to stdout. Prior to OTP 26 the stdio used when redirecting to a non-terminal was not unicode aware, so it would just shuffle the bytes.

If my hypothesis is correct , the solution would be to make group aware that user_drv is currently in latin1 mode and then skip the convertion. A PR would be very welcome!

[michalmuskala]

Ah, now that we know where to look we'll work on sending a PR

[michalmuskala]

Unfortunately, I did not have time yet to look into it a bit more deeply, but I'm leaving this comment for others that might be struggling with the regression as well.

Inside ELP we've "solved" this by migrating to "raw" stdio through a port. This involves starting the node with -noinput (note that -noinput -noshell causes some spurious error logs), and later on "opening" the stdin/out as a port with:

open_port({fd, 0, 1}, Opts)

with file descriptors 0 and 1 being standard for stdin/out.

It actually ends up more performant than before, and allowing for options such as active and {packet, N} on the port makes it somewhat more convenient to use.

I still plan on working on a fix for this in OTP, but it's somewhat less of a priority for us right now with this work-around.

[garazdawi]

Can you check and see if #9013 solves the issue for you?