bug-ncurses
[Top][All Lists]
Advanced

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

Re: overhead of _nc_tiparm


From: Thomas Dickey
Subject: Re: overhead of _nc_tiparm
Date: Thu, 5 Jan 2023 18:34:30 -0500
User-agent: Mutt/1.10.1 (2018-07-13)

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

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.

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

(patches to improve it are of course duly considered)

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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