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... -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
