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 <[email protected]> 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 > >
