directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <ayasel...@gmail.com>
Subject Re: Lookup operation performance with the modified JDBM
Date Tue, 18 Oct 2011 06:52:12 GMT
When changing jdbm, I had to do a deep copy to provide multiversioning
at jdbm level. Normally, this should not be necessary. However, at
ApacheDS, currently, there is no clear separation of IO layer and data
layer. When a writer gets an entry from JDBM or any other partition,
it modifies the entry directly. In case the entry is coming from a
cache, then the change is directly made visible to the readers. Since
at jdbm layer we do not know whether the caller gets the entry just
for reading or for modification, we make a pessimistic assumption and
make a deep copy of the entry.

This will go away with the txn changes I am working on. When a txn
gets an entry from the partition (the entry might come from any cache
or disk), it will clone the entry before modifying it. This way, we
will not have to do any deep copy at the jdbm level.

regards,
Selcuk

On Tue, Oct 18, 2011 at 9:35 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> Hi guys,
>
> I have done some profiling to see why we get a really slower processing of
> operations like lookup or search with the new JDBM code base : we always
> copy the value we get back from the JDBM partition, which means we
> deserialize entries or dns.
>
> Deserializing is an awfully costly operation. The result is that we get a 7
> times slower lookup (5000/s against 35000/s before) doing a copy for each
> entry we return.
>
> I have no idea if we can avoid doing such a copy, I just wanted to know
> where we were spending time for such an operation.
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>

Mime
View raw message