Re: overhead of _nc_tiparm

[Thomas Dickey]

On Fri, Jan 06, 2023 at 04:54:40AM +0100, Pavel Stehule wrote:
> pá 6. 1. 2023 v 0:34 odesílatel Thomas Dickey <dickey@his.com> napsal:
> 
> > On Thu, Jan 05, 2023 at 09:34:59AM +0100, Pavel Stehule wrote:
> > > Hi
> > >
> > > I am working on a pspg pager https://github.com/okbob/pspg/. Although I
> > did
> > > some optimializations, there is a flickering when there are a lot of
> > > redraws (after mouse events processing). Last month I was working on a
> > port
> > > on pdcurses for possible support mswin platform.
> >
> > offhand, I'd guess that it's doing a lot of separate updates/refreshes.
> >
> > If a curses program reads from the keyboard, I'd generally just use the
> > refresh call that happens automatically with wgetch.  Having multiple
> > windows complicates that, of course.
> >
> 
> pspg uses windows wnoutrefresh() and one doupdate().

yes, but the rate at which pspg calls those updates relates to the performance.

However the data gets to the screen, something has to determine what parts
will get updated and how often.
 
> I am not sure, but I think so I see flickering on my gnome terminal after
> some block moving operations - when I scroll windows around 20 rows up down.
> 
> 
> 
> 
> > > When I did tests with pspg compiled with pdcurses I didn't find
> > flickering.
> > > I know so pdcurses is more primitive than ncurses and it has reduced
> > > functionality, but the difference is significant.
> >
> > pdcurses is displaying in a graphics window (that's what the console
> > windows
> > are), and that has its own performance tradeoffs (i.e., it may not be
> > actually
> > modifying the display as often as your program calls refresh).
> >
> 
> I tested it in terminal - this is one of ports of pdcurses on linux

well, you could be talking about the X11 configuration (graphical) or
SDL (also graphical).  They'll both act very different from something
sending escape sequences in a terminal.

https://pdcurses.org/
https://pdcurses.org/sdl2/
 
> >
> > > I tried to run profiler and I see about 10% cpu time in function
> > _nc_tiparm
> >
> > ...but _nc_tiparm (and below) is analyzing and formatting escape sequences.
> >
> > That caches some stuff (to avoid re-analyzing a string to determine
> > how many parameters to process), but pdcurses doesn't use escape sequences,
> > doesn't actually _have_ a tparm/tiparm function -- it's only writing
> > character+color values for each cell -- so they'll be very different in
> > performance ;-)
> >
> 
> I know so it does not have any transformation. I understand so this is not
> fully comparable. The output produced by pdcurses can be different, and
> some performance issues can be on VTE too.
> 
> I did measurements of doupdate function. On pdcurses is below 1ms, ncurses
> does 4ms and more.
> 
> I understand that these low numbers are not significant for remote
> terminals. I tested local terminals.

running pdcurses through a remote connection might not be simple :-)
 
> > The caching saves 5-10% of the overall time (from memory - it's been a
> > few years...).  You don't mention the throughput though - a pager would
> > be mostly waiting for input rather than dumping bulk text to the terminal.
> >
> 
> This problem is only when I handle mouse wheel events. These events can go
> very quickly, and it forces users to update printable content and redraw
> too often per seconds - more than 20 per sec, and then it can be
> significant if doupdate is about 4ms (or more) or 1ms. And I am not sure if
> this is not  a problem on the VTE side, maybe there is not good
> synchronization with monitor refresh frequency.

VTE won't run remotely (though of course you can ssh someplace and send
the characters to your local terminal).

One way that some terminals get apparent performance is to notice if the
whole screen is being repainted -- and omit updates that happen before
that point (skipping steps).  Another is using double-buffering (so that
the updates happen in-memory before pushing out a whole-screen-update).
Those are outside what ncurses can do.
 
> >
> > > It is strange, because this function has a varargs interface so it cannot
> > > be too fast.
> >
> > Actually, whether it's using varargs or not, it has to determine how many
> > parameters to use, since those can all be either char* or long values.
> >
> > > Is it a known issue?
> >
> > It's a concern, but (aside from hard-coding sprintfs as some do), there's
> > not a lot of room for improvement.
> >
> 
> ok - I understand, and it has sense
> 
> I cannot say, so ncurses are slow, in 99% it is fast enough. Just I was
> surprised when I see mentioned function on top in profiler

profiling an application won't show the work that the graphical frontend (such
as the X server) does to update the display.  The application would be doing
a lot of waiting if performance is poor.
 
> Thank you for your reply

no problem

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature