[apparmor] Fwd: Re: [Patch 0/4] change accept node handling during expr tree set

[John Johansen]

On 06/23/2015 10:13 AM, Jamie Strandboge wrote:
> 
> I accidentally responded to John privately but meant to respond to the list, so
> forwarding here.
> 
> -------- Forwarded Message --------
> Subject: Re: [apparmor] [Patch 0/4] change accept node handling during expr tree set
> Date: Mon, 22 Jun 2015 14:39:44 -0500
> From: Jamie Strandboge <jamie at canonical.com>
> To: John Johansen <john.johansen at canonical.com>
> 
> On 06/22/2015 12:59 PM, John Johansen wrote:
>> This series of patches changes the way accept nodes are generated
>> and the expression tree is set-up around them. It is a start to the
>> backend refactoring and cleanup, and provides a nice little performance
>> boost in most cases because
>>   1. It reduces the number of accept nodes geneted and considered during
>>      simplification/factoring, and node set building (shorter node sets
>>      to construct and compare)
>>   2. It reduces the number of Alt nodes (used to combine the accept nodes)
>>      to consider during simplfication, and node set building (agin shorter
>>      node sets to construct and compare)
>>   3. It reduces the number of nodes that must be consider in any given
>>      simplification pass, by separating out node sets that can't be
>>      simplified on the right hand simplification/factoring pass.
>>
>> The performance change is dependent on the profile being parsed, and
>> there is no guarentee that it will be faster for all profiles. With that
>> being said, I haven't seen any performance regressions+ and some fairly
>> nice performance improvements so its worth considering before the rest
>> of the backend factoring is done.
>>
>> Eg. Using a few example profile tests from a local machine, comparing
>> against the 2.9 parser in Ubuntu 14.10 against current 2.10 with
>> these patches*
>>
>> profile       with tree simplification      -O no-expr-simplify
>> -------       -----------------------       -------------------
>> evince              22% faster                   10% faster
>> firefox             40% faster                   11% faster
>> chromium            32% faster                   11% faster
>> cupsd               35% faster                    3% faster
>> dnsmasq             12% faster                   17% faster
>> dhclient            36% faster                    5% faster
>> klogd                0%                           8% faster
>>
>> *Note: 2.10 is actually handicapped by a couple fixes to change_profile
>>  encoding that causes its dfa to have a few extra nodes.
>> +There was some regression, in a few cases on individual runs but when
>>  averaged over a few runs, the timing variations resulted in small net
>>  wins, in those cases.
> 
> I'm curious how this affects Ubuntu Touch and Core policy. Attached are three
> profiles-- can you try with these (and also add these three to wherever you are
> storing the test profiles)? Also, what architecture was this on? Did you test on
> arm?
> 
And the analysis has now been posted to the original thread