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 (athena.apache.org: domain of akarasulu@gmail.com
 designates 209.85.146.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=PdQdVtiBXQivcjXHPjaz2S6lggTISZcR4R8N05e0ZK4/zmpCty71rTAPceveunKqahVGLippRCfhefNHOaCbwgltpzLWejNT+elVT61OSUWXB7SZqn+mSlGy0HcNq8BPYtiw2uAllmNFhRf4ssWPnBFY+XUllnEqSnPtT9zah9s=
Message-ID: <a32f6b020802111826l6e79c802w88bb0b46cf26d653@mail.gmail.com>
Date: Mon, 11 Feb 2008 21:26:40 -0500
From: "Alex Karasulu" <akarasulu@apache.org>
Sender: akarasulu@gmail.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: splay tree for duplicate key cursor implementation
In-Reply-To: <47B0AD54.6000100@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_48316_8069211.1202783201218"
References: <47B0AD54.6000100@gmail.com>

------=_Part_48316_8069211.1202783201218
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks Kiran for posting our off line conversations here.

Alex

On Feb 11, 2008 3:17 PM, Kiran Ayyagari <ayyagarikiran@gmail.com> wrote:

> hi Guys,
>
>    During a discussion with Alex it was understood that implementing a
> linked
>    splay tree for duplicate key cursor may not result in any
> performance gain.
>
>    When we perform lookups on the splay tree (kept in memory after
> fetching the
>    serialized version )  its structure changes due to splaying.
>
>    This changed structure will be discarded without writing back to the
> disk to
>    eliminate the write cost. This way it will not help us in any form
> to get the amortized
>    time benefits.
>
>    So we are thinking of using some kind of btree for the actual
> implementation.
>
>  Thoughts?
>
> - Kiran Ayyagari
>
>

------=_Part_48316_8069211.1202783201218
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks Kiran for posting our off line conversations here.<br><br>Alex<br><br><div class="gmail_quote">On Feb 11, 2008 3:17 PM, Kiran Ayyagari &lt;<a href="mailto:ayyagarikiran@gmail.com">ayyagarikiran@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">hi Guys,<br><br> &nbsp; &nbsp;During a discussion with Alex it was understood that implementing a<br>linked<br>
 &nbsp; &nbsp;splay tree for duplicate key cursor may not result in any<br>performance gain.<br><br> &nbsp; &nbsp;When we perform lookups on the splay tree (kept in memory after<br>fetching the<br> &nbsp; &nbsp;serialized version ) &nbsp;its structure changes due to splaying.<br>
<br> &nbsp; &nbsp;This changed structure will be discarded without writing back to the<br>disk to<br> &nbsp; &nbsp;eliminate the write cost. This way it will not help us in any form<br>to get the amortized<br> &nbsp; &nbsp;time benefits.<br><br> &nbsp; &nbsp;So we are thinking of using some kind of btree for the actual<br>
implementation.<br><br> &nbsp;Thoughts?<br><font color="#888888"><br>- Kiran Ayyagari<br><br></font></blockquote></div><br>

------=_Part_48316_8069211.1202783201218--