Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of ersin.er@gmail.com designates
 64.233.182.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding;
        b=i3VlprNRkzV+xR86qaToC2CeXJ714UCy6b6f3dz6rYBWBVXhJvhV7dQPWoDdbetUONKepJt+cQh/HUQkdsazk/K66lvCApr74K6jAaDU+ovU9e2/cy5JjchaZ4HZC7Lj/9sul5rWQntUhFCTjQAOEy56YzPSYpZ7wZyjrw6BPf4=
Message-ID: <44BF86A1.8050206@gmail.com>
Date: Thu, 20 Jul 2006 16:35:29 +0300
From: Ersin Er <ersin.er@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060614)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Optimizing DB access with improving key usage 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

The optimization branch is busy with extensive refactorings and things 
are going well. We had a few convos recently for further improving the 
performance and one of the points of improvement was thought as 
replacing the BigInteger construct which we use as the key of Attributes 
objects in the database.

What we do when retrieving and Attributes object is first retrieving a 
BigInteger stored in the db for the normalized DN and then doing one 
more lookup for the actual Attributes object using the BigInteger as the 
key.

The first improvement to be done is to replace BigInteger with int or 
long which cost much less. But as Alex just (yes, at the time of writing 
this :) ) warned me about that jdbm keys should be objects not 
primitives. So my second suggestion is again replacing the BigInteger 
with more leightweight class like Integer and generating that Integer 
for each LdapDN at the time of construction. I think we do not need to 
do one more lookup to retrieve the (Big)Integer key of the Attributes 
object. We can just generate a hash value at LdapDN constructor and 
provide a method for accessing it when we want to store or retrieve 
Attributes objects. Of course, the hash code should be generated from 
normalized components of the DN. As a DN is a primary key for an LDAP 
tree, again a unique key generated from it will serve as the primary key 
for the whole backend DB.

WDYT ?

-- 
Ersin