Hi,

I am currently testing the difference in speed between query in DBISAM and ElevateDB

For the same Query, with DBISAM it's takes 2184 milliseconds and with ElevateDB it's takes 2991 milliseconds.

This is the query I execute :

SELECT * FROM Materiaux INNER JOIN Fournisseur ON (Materiaux.Fournisseur = Fournisseur.Code)

Why is it longer with ElevateDB ?

Thanks for your answer

Bruno Riviere

AJ SOFT

Bruno


1. Can you post the query plans for both please?
2. How are you doing the timing? When trying to do time tests I've had 100% variance due to caching

Roy Lambert [Team Elevate]

Roy Lambert <roy.lambert@skynet.co.uk> wrote:

Bruno


1. Can you post the query plans for both please?
2. How are you doing the timing? When trying to do time tests I've had 100% variance due to caching

Roy Lambert [Team Elevate]

Hi Roy,

1 - What is the query plans ?

2 - I do the timing like this : first in the BeforeOpen method I get time like this DT1 := now; (DT1 is a DateTime variable)
Secondly in the AfterOpen method I view the timming like this : MilliSecondsBetween(now,DT1);

bruno


Query plans are incredibly helpful and useful things. Generally they'll give enough information to optimize a query. The easy way of generating them is to run the query in DBSys or ElevateDB both have options to generate the plan.

In your own code then for ElevateDB, from the pdf manual

If you wish to retrieve a query execution plan for the current execution via the Plan property, then set the
RequestPlan property to True before executing the query.

You'll have to ser requestplan to true BEFORE executing the query. After you can save plan to file, assign it to a stringlist or view using plan.text.

For DBISAM its pretty much the same but use GeneratePlan rather than requestplan (Tim just like to confuse us).

Your timing is not going to be massively accurate. Use GetTickCount instead which is better or there are some high precision timer components for free on the web. Also look at the time in the plan. That, from memory, gives the actual execution time and excludes the query set up time.

Roy Lambert [Team Elevate]

Ok, Roy

I have make the plan for the both, you can see it in the zip file.

The file "PlanDBISAM.txt" is for the query with DBISAM

The file "PlanElevateDB.txt" is for the query with ElevateDB

Bruno


Looking at those they both appear to me to be optimised so its over to Tim.

Roy Lambert [Team Elevate]

So DBISAM is faster than ElevateDB ...

What is the interest of moving ElevateDB if not faster ?

Bruno


Firstly I'd wait until Tim has his say - he's the guru. Secondly if speed is your only concern then there are things out there faster than DBISAM. ElevateDB has more functionality, better adherence to the SQL standard (and a more up to date one as well), replication facilities and other things.

Overall my impression is that ElevateDB is faster than DBISAM but I don't have figures to back that gut feel up.

Roy Lambert [Team Elevate]

In my overal feel of things, EDB performs better.

I have to agree with Roy in the the feature improvements, updated and better
SQL compliancy, additional improvements for replication, catalog support,
etc, its just a much better product.

Also, the future of DBISAM is none (as far as I see, but Tim would have
final say).  Tim's been making a few minor updates for DBISAM, but nothing
new.  EDB is where the focus is on and expansion support for Lazurus and
other IDE's.

Lance




"Bruno" <br@ajsoft.fr> wrote in message
news:50F00AF0-7C9D-471B-833C-FA97ABE61B13@news.elevatesoft.com...
> So DBISAM is faster than ElevateDB ...
>
> What is the interest of moving ElevateDB if not faster ?
>

Lance


>SQL compliancy,

All I have to do is persuade him that NULL can = emptystring and  I'll be happy <vbg>

Roy Lambert