Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45B91C9C.8090500@ungoverned.org>
Date: Thu, 25 Jan 2007 16:09:48 -0500
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: Needed: LDAP expression evaluation optimization
References: <45B7BBC7.2060709@ungoverned.org>
 <001a01c740c3$9421ec40$ca09010a@gantenbein>
In-Reply-To: <001a01c740c3$9421ec40$ca09010a@gantenbein>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Jan,

The issue is that we have a set of capabilities (each a set of 
property-value pairs) that we must run filters over to find matching 
capabilities. The set of capabilities can grow to be pretty large if you 
consider OBR repositories, but even at run-time you can have quite a few 
capabilities since it includes all exported packages and bundles (I have 
heard of examples of bundles exporting 100's of packages).

So, assuming that we have a large set of capabilities, our new generic 
approach requires even more use of filters evaluated over these set of 
capabilities. So, the main reason why we have slowed down now is due to 
the fact that we have to use filters more and this will only be 
exacerbated as the number of capabilities grows in more complex use cases.

I assume what we need is some way to index the properties of our 
capabilities so that we can really quickly evaluate a given filter over 
the set of capabilities to find all that match. This is just my hunch.

If you think that you have something that can help out, I am all ears. :-)

-> richard


Jan S. Rellermeyer wrote:
> Hi Rick, 
>
> Is your concern more that the evaluation of the expressions is not
> performing well because of the performance of the filter implementation or
> is it that you have redundancy in the expressions and you want to (runtime)
> optimize the expressions themselves? If first is the case, I might be able
> to contribute my LDAP filter implementation used in Concierge and jSLP. It
> went through a large series of profiling and benchmarking and is really
> quite speedy in both parsing and evaluation. In case you want to test it,
> let me know.
>
> Cheers, 
>
> Jan. 
>
> -----------------------------------------------------------
> ETH Zurich, MSc Jan S. Rellermeyer,
> Information and Communication Systems Research Group (IKS),
> Department of Computer Science, IFW B 47.1, 
> Haldeneggsteig 4, CH�8092 Z�rich 
> Tel +41 44 632 30 38, http://www.iks.inf.ethz.ch
> -----------------------------------------------------------  
>
>   
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org] 
>> Sent: Wednesday, January 24, 2007 9:04 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Needed: LDAP expression evaluation optimization
>>
>> Consider this a call for contributions.
>>
>> The latest changes to Felix' resolver adopt a generic 
>> capability/requirement approach for resolving package 
>> export/import and bundle provide/require constraints (with 
>> the goal of also using this approach for host/fragment 
>> constraints too).
>>
>> The benefit of this approach is that it provides a nice 
>> generic way off adding and resolving additional types of 
>> constraints to the Felix resolver. Another benefit is that 
>> this resolver implementation can be shared with OBR, so the 
>> same resolver can be used for deployment as well as runtime wiring.
>>
>> The downside of this approach is that it relies heavy on LDAP 
>> expressions and their evaluation, which tends to slow things 
>> down a bit.
>>
>> To offset this slowdown, I have cut some corners making the 
>> capabilities/requirements not as generic as I would like. I 
>> want this approach to be as generic as possible, but this 
>> requires that we optimize LDAP expression evaluation.
>>
>> If anyone has experience in such areas and is willing to look 
>> into this area for Felix, please let me know and I can 
>> explain more precisely what we need. Overall, I think the 
>> work should be pretty localized, so it should be an easy way 
>> to get involved for someone with experience in this area.
>>
>> Search your soul, you know you want to contribute! ;-)
>>
>> -> richard
>>
>>     
>
>