Re: [PATCH] gdb: unbuffer all input streams when not using readline

[Andrew Burgess <aburgess@redhat.com>]

* Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> [2022-01-18 11:26:42 -0500]:

>
> The change looks ok to me (better than the status quo), given that
> correctness is more important than performance.
>
> I'm just wondering if there's a noticeable performance difference
> between having the input buffered vs unbuffered.  Calling fgetc with
> unbuffered input means we do one syscall per character.  With frontends
> sending tons of commands, it could possibly affect the responsiveness
> and degrade user experience.  But it's just a guess, we should be able
> to measure it.

I'm planning to go ahead and push this patch - I'll give it a couple
more days in case someone wants to shout stop!

On input performance:

  - I tested this and was a <1% slow down, which seem acceptable to
    me,

  - I notice that readline reads its input one character at a time
    too, so now our non-readline input is handled the same way,

  - This function is not used for reading commands from a file (I did
    a simple test, and didn't hit this function), so shouldn't impact
    that case at all.

On output performance:

  - The unbuffering will only impact the output file descriptor for
    the new-ui case, usually, in all other cases, in and out are
    separate file descriptors,

  - The new-ui command only really makes sense for spinning up mi
    interpreters,

  - The mi interpreter buffers its output in string_files (see
    mi/mi-out.c), and then writes the output in a single command, so
    we shouldn't see any change in performance.

As this patch fixes a real bug, I think, lets merge this now, and if
there's any issues later, we can figure out what to do then.

Thanks,
Andrew