is performance going to improve once 0.7.0 is released?

[gansm]

is performance going to improve once 0.7.0 is released?

[gansm]

Where do you see a decrease in performance?

• Do the programs start slower?
• Is compiling slower?
• Is the screen refresh delayed?
• Do the programs react delayed to mouse and keyboard input?
• With which terminals have you tested?
• Which operating system do you use?
• On which cpu architecture did you test.
• Which compiler in which version did you use?
• What screen output do you get with "examples/rotozoomer -b"?
• Can you create a sample code with "std::chrono" that shows the performance degradation?

[alavaelian]

i think a TUI already have an incredible perfonmance than a GUI

[mooskagh]

I don't think it's much of a problem, but for me moving a window feels much more "laggier" in finalcut vs turbovision (taken from https://github.com/magiblot/tvision).

I've recorded a video which compares two "hello world" apps (https://www.youtube.com/watch?v=jOasaoRkR3Q). Not sure whether it's noticeable on the video but with mouse it feels that turbovision is much smoother.

You can see during the vertical moves, that in FinalCut mouse goes out of the window before the window is updated, while in tvision it follows the cursor.
It may also be helpful to watch the video frame by frame (press , and . keys on youtube, i.e. < and > without shift)

Terminal I use: alacritty
Operating system: Arch linux
CPU arch: x86_64

$ ./rotozoomer -b
Benchmark:
-------------------------------------------------------
Terminal            Size    Time      Loops  Frame rate
-------------------------------------------------------
xterm-256color      136x77  0.326s    314    963.190fps

[mooskagh]

Just checked on 0.5.1, it was similarly slow, so not sure that the issue starter meant the same issue as I.

[gansm]

Thanks for the great review in your comparison video. You can speed up the "hello world" example by activating the non-blocking-read mode. But this causes a higher CPU load.

#include <final/final.h>


int main (int argc, char* argv[])
{
  // Create the application object
  finalcut::FApplication app{argc, argv};

  // Enable the non-blocking reading mode
  app.setNonBlockingRead();

  // Create a simple dialog box
  finalcut::FMessageBox mbox{&app};
  mbox.setText("Hello world");

  // Start the application
  mbox.exec();
}

[gansm]

I have improved the output speed on the terminal a bit with the last commit (3c467c9).
I would be very pleased about positive feedback on this.

[mooskagh]

Neither setNonBlockingRead() nor syncing to the latest master (commit b69f3fc ) seemed to (noticeably) help.

Note that I personally don't see this issue as an important problem, I just tried to guess what the issue starter meant.

[gansm]

It is a pity that you did not notice any improvement when moving the window. Additionally, I increased the keyboard interval from 13.3 Hz to 30 Hz for fast mouse movements. (commit 531eb22)

[magiblot]

I have taken a look at the source code, and these are my conclusions:

• The main cause of FINALCUT's sluggishness are the timeouts that were intended to avoid 100% CPU usage. The reason is that the application cannot process new events while it is sleeping. You can test this by setting all timeouts to 0 in fkeyboard.cpp. The following are the first two solutions to this issue that I can think of:

  • A multi-threaded "single consumer, multiple producers" model where input is read from separate threads and the main thread waits for a limited time with something like std::condition_variable::wait_for. I tried this once, but I could not manage to process SIGWINCH events from the separate threads. It also took me some time to get all the mutex locking right.

  • Rely on the timeout feature of system calls such as select, poll or epoll. This is what I do now in Turbo Vision. In the case of poll, you can build a list of struct pollfd with every file descriptor you may receive input events from (stdin, gpm_fd, etc.), and a list of handler functions that are supposed to read from each of these (e.g. a function for stdin (Ncurses in my case), a function for Gpm, etc.). This allows you to await for all input events from a single system call. Additionally, if you need to wait for some sort of custom event you can create a pipe, add the readable end to the list, and write into it when the event is ready to be processed.

• There's a second issue with the "terminal update skipping" feature. This is a very important optimization, as discussed in cosmos72/twin#61, but it's not working right. If you try FINALCUT on the Linux console with Gpm and drag a window quickly enough, you will realize that the screen is not refreshed until you stop moving the mouse. This is caused by a small mistake in FVTerm::updateTerminal where skipped_terminal_update is always set to zero and so it never reaches max_skip. The following seems to fix it:

  - skipped_terminal_update = 0;
    std::size_t changedlines = 0;
    static constexpr int check_interval = 5;
  
    for (uInt y{0}; y < uInt(vterm->height); y++)
    {
      if ( updateTerminalLine(y) )
        changedlines++;
  
      if ( changedlines % check_interval == 0
        && (keyboard->hasUnprocessedInput() || keyboard->isKeyPressed(0))
        && skipped_terminal_update <= max_skip )
      {
        // Skipping terminal updates if there is unprocessed inputs
        skipped_terminal_update++;
        return;
      }
    }
  + skipped_terminal_update = 0;

  skipped_terminal_update is already zero-initialized on its first use as per its definition at the beginning of fvterm.cpp.

Cheers.

[gansm]

Thanks for your detailed analysis and review. I have now optimized the input routines again. Now FINAL CUT queues keyboard and mouse input for faster conversion to widget events.

You have correctly identified the problem with the timeout. Before I used a timeout, I had a too high CPU load in idle because, in the non-blocking read mode, the event loop called the select function too many times in a sequence (see #59).

I also already had the idea of a thread-based solution for reading keyboard input. Since I am in the process of releasing a new version, I will not make such a massive intervention at this time.

Resetting the skipped_terminal_update value is indeed done on the wrong line, which was not my intention. The "terminal update skipping" was primarily implemented by me because of the poor GPM performance.

I hope that this has brought some speed improvement to FINAL CUT. But I don't know if the issue opener @AndreiSva has seen its performance problems here.

[mooskagh]

I've just checked, and can confirm that finalcut feels much more responsive now than it was before.

However tvision still feels a bit slickier (again, I don't think there is any usability problem, this is not a huge problem at all).

[gansm]

Many thanks for testing. It's nice that my optimizations could improve the user experience a bit. Since @AndreiSva did not give me any further feedback, I will now release version 0.7.0.

[gansm]

Now the terminal's refresh rate is limited to 60 Hz. Moving windows should now be a bit more fluid.

commit 25f2abe