Hi everyone

I realize the method SetRange in ElevateDB is much slower than DBISAM. I have the same table with 2 milion records in DBISAM format and ElevateDB format. If I call the method SetRange with the same arguments in DBISAM it is almost instantaneous but in ElevateDB it takes one second or two. The result set will result in almost 500k records.

Anyone else noted the same situation ?

Jose,

Are you sure you are doing it the same way?
I mean both remote/local connections, same hardware, etc.. ?

--
Fernando Dias
[Team Elevate]

Fernando

<<
Are you sure you are doing it the same way?
I mean both remote/local connections, same hardware, etc.. ?
>>

Yes. The condition to run both SQL in ElevateDB and in DBISAM are exactly the same. Same data, same indexes, some machine. Some C/S settings, etc.

I am still trying to understand what happened but for now I really do not know.

Eduardo

Jose


Out of interest what speed do you get if you use a sensitive query?

Roy Lambert

<<
Out of interest what speed do you get if you use a sensitive query?
>>
The first time it takes 2.5 seconds but the second time it takes 0.125 seconds.

I am doing the tests using F/S only.

After digging down the situation is:

Unit: dblocal

function TEDBFilterIndexNavigator.BuildOptimizedRangeBitmap

There is a while in this function that perform 593673 times (one for each record in the final dataset) it is the cause of slowdown. In DBISAM the idea and code are much different.

But like I sad the first time it takes much more time than second and others.

Eduardo

Jose


What you've found would go along with this

<<Yep.  It's basically related to the fact that we're pumping the range
functionality through the filter functionality now in EDB, whereas the two
were separate in DBISAM.   It's all part of the code streamlining in EDB
that tries, at all costs, to keep things much simpler and, therefore, more
robust.>>

from Tim back in 2007.


This "Unit: dblocal" looks like a Delphi unit should it be edblocal?

Roy Lambert

ps congratulations for being brave enough to buy the source and look through it.

Roy

<<
This "Unit: dblocal" looks like a Delphi unit should it be edblocal?
>>
Sorry, you are right, the name of unit is "edblocal"

<<
ps congratulations for being brave enough to buy the source and look through it.
>>
It is rare to open the source code but sometimes I go inside to search something new.

Eduardo

Eduardo,

<< I realize the method SetRange in ElevateDB is much slower than DBISAM. I have the same table with 2 milion records in DBISAM format and ElevateDB format. If I call the method SetRange with the same arguments in DBISAM it is almost instantaneous but in ElevateDB it takes one second or two. The result set will result in almost 500k records. >>

A range, by itself, is handled like a filter in ElevateDB, whereas with DBISAM it isn't.  The additional time required to build the filtered set is what you're seeing.

Unfortunately, this is architectural and a choice made so that combining ranges and filters doesn't cause performance to drop off a cliff, which was the case with DBISAM when this happened.  The *average* performance is better, but specific instances like yours are worse.

Tim Young
Elevate Software
www.elevatesoft.com