[Top][All Lists]

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

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

From: Bryan Christ
Subject: Re: API pair_content() call is about 7x slower on Fedora 29 vs Bionic
Date: Sun, 30 Dec 2018 19:30:34 -0600


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.



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>


reply via email to

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