[Index] OneLevel index removal, performances

[Emmanuel Lécharny <el...@gmail.com>]

Hi guys,

Kiran and I conducted some quick performance tests to compare the 
numbers we get with the server with no OneLevel index compared to the 
trunk before the merge. It's quite interesting :

Operation (before/after) per second

Add : 222/264 (me) 649/746 (Kiran)
Delete : 156/191 (me) 442/544 (Kiran)
Search : 5215/5214 (me) 19932/20335 (Kiran)
Move : 308/303 (me)
Rename : 380/392 (me)
MoveAndRename : 204/275 (me)

My machine is an old Linux computer with an old CPU, Kiran has a quad 
core recent computer.

The modifications are now around 20% faster (add/delete). The Move 
operation has been deeply modified and is not optimal in the new 
operation. We can most certainly improve it.

The very nice point is that searches are not slowed down by the removal 
of the index.

Let's expect that the subLevelIndex removal will carry some new perf 
improvements !

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [Index] OneLevel index removal, performances

[Alex Karasulu <ak...@apache.org>]

On Wed, Apr 11, 2012 at 5:55 PM, Emmanuel Lécharny <el...@gmail.com>wrote:

> Hi guys,
>
> Kiran and I conducted some quick performance tests to compare the numbers
> we get with the server with no OneLevel index compared to the trunk before
> the merge. It's quite interesting :
>
> Operation (before/after) per second
>
> Add : 222/264 (me) 649/746 (Kiran)
> Delete : 156/191 (me) 442/544 (Kiran)
> Search : 5215/5214 (me) 19932/20335 (Kiran)
> Move : 308/303 (me)
> Rename : 380/392 (me)
> MoveAndRename : 204/275 (me)
>
>
What exactly do these numbers correspond to? Is this a single operation or
are they averages? Also I see for your machine you have a number/number -
what's this mean?


> My machine is an old Linux computer with an old CPU, Kiran has a quad core
> recent computer.
>
>
This definitely should mean your disadvantaged however there are other
considerations besides just CPU like disk access speeds. However if your
machine is much older it's feasible that it's disk is slower.

It's best regardless to compare these operations on the same machine.


> The modifications are now around 20% faster (add/delete).


That's awesome but can you run it on the same hardware? That way it might
actually be more.


> The Move operation has been deeply modified and is not optimal in the new
> operation. We can most certainly improve it.
>
> The very nice point is that searches are not slowed down by the removal of
> the index.
>
>
I think we need more tests to confirm this if we're only performing a
single search. There are several parameters to the search and if we're
doing a single entry lookup we might not be seeing the impact fully.


> Let's expect that the subLevelIndex removal will carry some new perf
> improvements !
>
>
I hope so too. This is great work ... I'm just curious about the results.
If you need more test resources I can help out as well.

-- 
Best Regards,
-- Alex

Re: [Index] OneLevel index removal, performances

[Kiran Ayyagari <ka...@apache.org>]

yeap, pleased to see the improvement in performance, considering the
amount of effort you put in
thanks Emmanuel

On Wed, Apr 11, 2012 at 8:25 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Hi guys,
>
> Kiran and I conducted some quick performance tests to compare the numbers we
> get with the server with no OneLevel index compared to the trunk before the
> merge. It's quite interesting :
>
> Operation (before/after) per second
>
> Add : 222/264 (me) 649/746 (Kiran)
> Delete : 156/191 (me) 442/544 (Kiran)
> Search : 5215/5214 (me) 19932/20335 (Kiran)
> Move : 308/303 (me)
> Rename : 380/392 (me)
> MoveAndRename : 204/275 (me)
>
> My machine is an old Linux computer with an old CPU, Kiran has a quad core
> recent computer.
>
> The modifications are now around 20% faster (add/delete). The Move operation
> has been deeply modified and is not optimal in the new operation. We can
> most certainly improve it.
>
> The very nice point is that searches are not slowed down by the removal of
> the index.
>
> Let's expect that the subLevelIndex removal will carry some new perf
> improvements !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>



-- 
Kiran Ayyagari