Hi,

I am just in the midst of a upgrading an application that uses DBIsam 3.30 to DBIsam 4.32. After a few little hickups I was able to run the application but instantly noticed a drop in performance. Since I was sure the problem was in the application I ran some very easy queries within the Database System Utility and was very surprised to see my "feelings" confirmed:

The following simple query takes just 0,688 seconds with 3.30 but a whopping 1,985 seconds within 4.32. This is more than twice as much time...

SELECT LfdNr, VU, Spalte15 FROM RanglistenDaten ORDER BY LfdNr

Once thing that is strange, is that the amount of returned rows differ by one (31155 for version 3 and 31156 for version 4).

The table was upgraded using "Upgrade table" in the utility, the primary index of the table is on the column "LfdNr". There are 24 columns is the table, mostly strings. Both databases (or better both directories) are on the same PC running under WIN XP SP3

I am a longtime, satisfied customer of DBIsam and can't think that this is by design. Something must be wrong on my side, but what?

I have attached a screenshots to support my claim...

Andrea


I'd worry more about the row difference before the speed. Try repairing both tables and see if you still get the problem. If so try and spot the errat row. If there is one I'd then email Tim directly and ask his help.


Speed is always a problem. I've had differences greater than the ones you're quoting caused by the various buffering mechanisms. Its also a subject that's been brought up before on these newsgroups so a search may turn up sone useful info.

From memory I think what you can do is tweak the DBISAM buffer settings. I'm using ElevateDB these days so all I have to go off is memory. THe manual should give you some info on the buffers available.


Roy Lambert [Team Elevate]

Hi,

thanks for the answer!

I was able to get rid of the different recordcount by repaiting both tables and redoing the update.

Regarding the loss of performance, I found out that when I remove the encryption from the tables the speed is back to what it was with DBIsam 3... Was the way DBIsam is handling encryption changed from version 3 to 4?

Greetings,
Pascal

Yes - v3 used XOR encryption while v4 uses Blowfish which is better but quite possibly slower.

Raul

<<

Pascal Joyeux wrote:

Was the way DBIsam is handling encryption changed from version 3 to 4?
>>

Oh, ok... I just read it in the manual too...

Funny, that I seem to be the only one who feels this drop in performance regarding encrypted tables. So I guess I will revert back to non-encrypted tables, since not all really need it.It was just easier with DBIsam 3 to just have them all encrypted even if it wasn't always needed...

Thanks for your help!

Regards,
Pascal

Raul wrote:

Yes - v3 used XOR encryption while v4 uses Blowfish which is better but quite possibly slower.

Raul

<<

Pascal Joyeux wrote:

Was the way DBIsam is handling encryption changed from version 3 to 4?
>>
&#9824;

Pascal

No you are not the only one. This is the reason I don't encrypt tables
anymore. The speed degration was to much for me, as to use it.

Regards
Rolf

"Pascal Joyeux" schrieb im Newsbeitrag
news:1F621493-B6BD-4331-AF66-3FE0121DC329@news.elevatesoft.com...

Oh, ok... I just read it in the manual too...

Funny, that I seem to be the only one who feels this drop in performance
regarding encrypted tables. So I guess I will revert back to non-encrypted
tables, since not all really need it.It was just easier with DBIsam 3 to
just have them all encrypted even if it wasn't always needed...

Thanks for your help!

Regards,
Pascal

Raul wrote:

Yes - v3 used XOR encryption while v4 uses Blowfish which is better but
quite possibly slower.

Raul

<<

Pascal Joyeux wrote:

Was the way DBIsam is handling encryption changed from version 3 to 4?
>>
&#9824;

Pascal,

<< Funny, that I seem to be the only one who feels this drop in performance
regarding encrypted tables. So I guess I will revert back to non-encrypted
tables, since not all really need it.It was just easier with DBIsam 3 to
just have them all encrypted even if it wasn't always needed... >>

Just to clarify:  the DBISAM 3.x "encryption" was actually only obfuscation,
and could be easily reversed.  The DBISAM 4.x encryption uses strong crypto
and one-way password hashes, so it cannot be reversed or un-encrypted
without the original password.  However, it is a bit slower, so you should
only use it on tables that absolutely need the encryption.

--
Tim Young
Elevate Software
www.elevatesoft.com