bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: overhead of _nc_tiparm


From: Pavel Stehule
Subject: Re: overhead of _nc_tiparm
Date: Fri, 6 Jan 2023 04:54:40 +0100



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().

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
 

> 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.

 

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.
 

> 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

Thank you for your reply

Regards

Pavel


(patches to improve it are of course duly considered)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]