On Wed, Apr 11, 2012 at 5:55 PM, Emmanuel Lécharny <firstname.lastname@example.org>
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.