Re: API pair_content() call is about 7x slower on Fedora 29 vs Bionic

[Bryan Christ]

Thomas,

I saw the patch but haven't yet tested with it.   However, I spent some time

contemplating real, practical implementations of ncurses and what those apps

typically look like.  Applying the 80/20 rule, I would say that most apps

use only a handful of color pairs... somewhere in the range of 4 - 8 but on my

emulator I enumerate all 64 pairs because I simply don't know what the app

will require.  It's probably a worse situation for other terminals

that support 256 pairs.  I think tiny LRU cache would make all the

difference... something like clock or gclock with about 6 slots.  The

code would be quite small but the performance gains would be substantial.

The question is would this be something that ncurses would benefit from as

a whole, or is this just something I should pursue myself.  Let me know if

you'd be interested in taking a patch for that.  If not, I'm still going

to add it to my library.  Just let me know either way.

On Sat, Dec 29, 2018 at 5:23 PM Thomas Dickey <address@hidden> wrote:

On Sat, Dec 29, 2018 at 09:48:01AM -0600, Bryan Christ wrote:
> I realize the linear searches are not good but there's no easy way
> around it.  Libvterm inits 64 color pairs (8 x 8) in keeping with the
> 64 colors allowed by the RXVT definition.  I do this because I have no
> way of knowing how many / which colors some program running under the
> emulator will need.  In the case of the demo program that gets built
> with libvterm, I, as the implementer/integrator of the library, know how
> to best look-up those color pairs and can therefore provide a better
> callback.  I don't know that other users of the library will do the
> same so it would be ideal if the performance could be at least as good
> as on Bionic with the default linear lookup using pair_content().

hmm - the improvement I saw (reducing calls to _nc_reserved_pairs by
inlining the checks) works well enough (according to gprof...),
but there is at least another factor: whether the sp-funcs feature is used.

See

https://github.com/ThomasDickey/my-autoconf-snapshots/blob/master/AcSplit/CF_ABI_DEFAULTS

it's a standard part of ABI 6, and accounts for the function names ending
with "_sp".  That adds a little to the time since it adds a layer of
function calls.

The Fedora trace shows it's being used (the rpm spec says it builds
ABI 5 and ABI 6, without overriding that feature); Bionic doesn't:
        a) it's still using ABI 5, and
        b) Ubuntu copies Debian packages.  Debian testing has ABI 5 and 6,
           so sometime Ubuntu will get it (there's always a delay).

The _nc_reserve_pairs code is used as part of new functionality to
support color pairs past 32767. sp-funcs is used to help developers
write reentrant code.  Speeding either of those up by eliminating
a layer of calls would require lots of code duplication.  (If someone
has _other_ approaches to improving performance, that's interesting).

By the way, Debian's ABI 6 development overrides part of the ABI defaults
listed above (the chtype/mmask_t details), so it wastes space.  I mentioned
that before.

--
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

--

Bryan
<><