On 2/14/20 2:51 PM, Ondrej Mosnacek wrote:
On Fri, Feb 14, 2020 at 6:37 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 2/13/20 8:39 AM, Ondrej Mosnacek wrote:
According to profiling of semodule -BN, ebitmap_cardinality() is called
quite often and contributes a lot to the total runtime. Cache its result
in the ebitmap struct to reduce this overhead. The cached value is
invalidated on most modifying operations, but ebitmap_cardinality() is
usually called once the ebitmap doesn't change any more.
After this patch, the time to do 'semodule -BN' on Fedora Rawhide has
decreased from ~14.6s to ~12.4s (2.2s saved).
Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
This seems fine but I was wondering how many of the callers of
ebitmap_cardinality() actually need anything more than ebitmap_length()?
The caller that calls it the most (>99%) during a 'semodule -B' is
__cil_should_expand_attribute(), which logically needs the actual
cardinality. It might be possible to cache the decision directly in
'struct cil_typeattribute', but I don't know the CIL code well enough
to attempt that...
That's fine - I'm ok with the patch itself. I just happened to notice
that there appear to be quite a few callers elsewhere in libsepol that
only seem to care whether the result is zero or non-zero, which
seemingly would be just as happy using ebitmap_length().
