Re: [BuildStream] Responsive, but not overly verbose UX - not-in-scheduler

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi Ben,

On Tue, 2019-04-23 at 19:13 +0000, Benjamin Schubert wrote:
> Hey all,
>
> I think having a single UI is definitely a good idea and would make
> things simpler. I agree with the high-level plan this thread is
> heading to.
>
> I just have a single concern about it, the UI is already very slow
> (turns out it's even a bottleneck sometimes), so I would be very
> careful if we make it more complex that we don't make it slower than
> before or prevent some optimizations there. Also, we probably don't
> need the fully flegged UI when running in non-interactive mode, so we
> might want to have two different implementations for better
> performance.

So about performance of logging, really what it comes down to, logging
is just printing characters to the console, and there are parts which
we can enable/disable to gain performance where suitable.

Currently there are some potential areas for improvements here:

  * Disabling colors

    When running without colors, we are not getting the performance
    benefits that we should be getting (although I don't really know
    how significant those benefits actually might be, would be worth
    trying to benchmark).

    I.e., instead of losing the codepaths which add ansi escape
    sequences in the first place, we just strip out the escape
    sequences before sending text to the console (so it is in fact
    *less* performant with colors turned off than on).

  * We could "tick" less than once per second

    We "tick" every second in order to provide nicer feedback in the
    status bar, this could be configurable.

  * We could update the status bar less when tasks start/complete

    We didn't really have remote execution in mind when designing the
    UI, and if there really are a *lot* of tasks starting and stopping,
    that can cause us to update the UI more than we need, we could bind
    the status bar updates to really be strictly only once per second
    regardless of started/stopped tasks (or once per a "ticks-per-hour"
    preference that could be configurable).

  * Disable the status bar completely.

    We could have an option for disabling the status bar.

    Currently we only automatically disable it where we know that we
    cannot display it (either not connected to a tty, or connected to
    a tty which doesn't support the required escape sequences for
    cursor positioning).

    I don't think it makes any sense to piggyback on the 'interactive'
    setting to disable the status bar though, that seems to be
    conflating whether interactive prompts should ever show up (for
    build breaks, ^C, or anywhere else for scripting purposes), with
    whether we want to see a status bar, so I would rather a separate
    setting for this.

I should also point out that verbose mode is currently default, which
basically means we see the STATUS messages which we would not see if we
turn off verbose (also, iirc, in non-verbose mode the STATUS messages
are just not sent to the main UI/scheduler process at all).

I *think* I had also initially set it up so that nested
START/SUCCESS/FAILURE messages are not enabled unless in verbose mode,
but I don't think that was retained, it could be restored though to
achieve a non-verbose mode which only had:

  * START/SUCCESS/SKIP messages only for the global task, not nested
  * INFO, WARNING, FAILURE, and BUG messages

Hope this is helpful :)

Cheers,
    -Tristan