Hi,

Just discovered that in C/S mode the lookups are much slower than in DBISAM C/S. Played
around with RemoteReadSize, but no change.

Is this "normal" behaviour ? Anything I can do ?

TIA,

Heiko

Did a little more testing.

Network, 2 tables, 1000 lookups using primary index :

DBISAM: 220 ms
DBISAM C/S: 600 ms

EDB: 420 ms
EDB C/S: 6200 ms (!)

Heiko


Can you post your test project code to the binaries ng please. I for one would like to see what it is, and give it a test over here. I'm sure Tim would like to do the same.

Roy Lambert [Team Elevate]

Roy

I tested from within my application, so the whole connect stuff and the database/tables
had been present. It would take a while to extract a standalone test project from that.
Will do so of course, but before that I would like somebody to tell me "Hey, here the
EDB-CS-lookups are as fast as the DBISAM ones"  

That's the (not very sophisticated) test procedure, maybe you can adapt it and try it in
one of your projects.

--------------------------

var table1, table2: TDBISAMTable/TEDBTable;
   a: Integer;
   str: String;
   timerstart, timerstop: TDateTime;
begin
  table1 := opentable('auftrag_a');
  table2 := opentable('messwerte_a');
  table1.IndexFieldNames := 'aufnr';
  table2.IndexFieldNames := 'aufnr;probenr;pnr';

  
  a:=0;
  table2.First;
  timerstart := Now;
  while not table2.Eof do begin
     if a=1000 then Break;
     str := table1.Lookup('aufnr', table2.FieldByName('aufnr').AsInteger, 'bezeichnung');
     inc(a);
     table2.Next;
  end;
  timerstop := Now;

  table1.Free;
  table2.Free;

  showmessage(inttostr(millisecondsbetween(timerstart-timerstop)));
end;

------------------------------

Heiko

Heiko

Have you tried with FindKey instead of Lookup ?

Eduardo

Eduardo,

>>Have you tried with FindKey instead of Lookup ?

Just tried...exactly the same.

Heiko

Heiko

>>>Have you tried with FindKey instead of Lookup ?
>
>Just tried...exactly the same.

That was going to be my next question.

The next one was going to be - what about a prepared query?

I'll need to convert a couple of tables (I don't have anything just now with an identical structure). If Tim doesn't respond beforehand I'll see what I can do tomorrow.

Roy Lambert [Team Elevate]

Heiko,

<< Just discovered that in C/S mode the lookups are much slower than in
DBISAM C/S. Played around with RemoteReadSize, but no change.

Is this "normal" behaviour ? Anything I can do ? >>

I'm not seeing that level of difference at all.  With ~1000 lookups:

DBISAM C/S: 78 ticks
EDB C/S: 178 ticks

I need to do some more investigation into why there's even 100 ticks
difference.

Are you using 2.01 ?  Also, are you sure that there aren't any filters
defined, or anything like that ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>>I'm not seeing that level of difference at all.

OK, I will create a test project tomorrow and see if it has something to do with my app,
or with the tables I used. Thanks for testing.

>>Are you using 2.01 ?  

Yes.

>>Also, are you sure that there aren't any filters defined, or anything like that ?

No. I posted the procedure I used above...the opentable() just creates a table, sets
SessionName, DatabaseName and TableName, and returns it.
Both servers and databases are on the same harddisk, the same machine on the network.
The tables are basically the same, migrated, only change of the EDB ones is that all
varchars are altered to COLLATION DEU_CI_AI_KI_WI DEFAULT '' NOT NULL.

I experienced another difference when running the above mentioned procedure: At the first
run, DBISAM took twice as long, about 1200ms, and the 2nd, 3rd, etc. run it was always
about 600ms. EDB took its about 6200ms every run.

Heiko

Heiko,

<< No. I posted the procedure I used above...the opentable() just creates a
table, sets SessionName, DatabaseName and TableName, and returns it. Both
servers and databases are on the same harddisk, the same machine on the
network. The tables are basically the same, migrated, only change of the EDB
ones is that all varchars are altered to COLLATION DEU_CI_AI_KI_WI DEFAULT
'' NOT NULL. >>

It's possible that it may be due to the collation you're using and/or the
lengths of the columns that you're using.  I tested it with integer columns,
which may be accounting for the difference.  If you could at least get me a
copy of the tables that you're using, I can test it further.

Also, just so you know - you don't need the KI or WI modifiers for the DEU
collation so they can safely be left out.

--
Tim Young
Elevate Software
www.elevatesoft.com