Board index » delphi » Bench Test with BDE 16b and BDE 32b ?!

Bench Test with BDE 16b and BDE 32b ?!

Hello all,

I make a test  comparativ with  Bde 2.51 ( 16bit Delphi 1 ) and Bde 5.01 (
32bit Delphi 4 ), and the result is stupid. Why this result ?

Le test is 3 query with paradox tables.
The machine is  reboot and very clean.
The connection to the database is OK. ( Session.opendatabase ( DatabaseName ) )

The time test is the actived of the 3 querys

in second time the Tquerys are false avtived.

and the 3 Tquerys are actived  ( memory cache is using)
_______________________________________
!                  !    1er calcul    !    2ime calcul   !
!  Bde 16      !    3"40           !       0"70            !
!  Bde 32      !    7"00           !       3"20            !
-----------------------------------------------------------
Why please ?  

 

Re:Bench Test with BDE 16b and BDE 32b ?!


The 32bit architecture introduces considerable overhead.
A plus side to this is that you can use threads to improve
responsiveness of an app and if your app crashes it won't
corrupt other running processes.  That's the theory anyway.

16bit BDE functionality is no longer being actively supported
by dang near anyone these days, so even if the 16bit
architecture was 10 times faster it doesn't really matter.

One thing to remember is that the 16bit BDE supports far
less SQL features than the 32bit version.

GW.

Quote
SYNAPTIQUE <synapti...@aol.com> wrote in message

news:19991001091624.26876.00000394@ng-fp1.aol.com...
Quote
> Hello all,

> I make a test  comparativ with  Bde 2.51 ( 16bit Delphi 1 ) and Bde 5.01 (
> 32bit Delphi 4 ), and the result is stupid. Why this result ?

> Le test is 3 query with paradox tables.
> The machine is  reboot and very clean.
> The connection to the database is OK. ( Session.opendatabase
 DatabaseName ) )

> The time test is the actived of the 3 querys

> in second time the Tquerys are false avtived.

> and the 3 Tquerys are actived  ( memory cache is using)
> _______________________________________
> !                  !    1er calcul    !    2ime calcul   !
> !  Bde 16      !    3"40           !       0"70            !
> !  Bde 32      !    7"00           !       3"20            !
> -----------------------------------------------------------
> Why please ?

Re:Bench Test with BDE 16b and BDE 32b ?!


Quote
Graham Wood wrote:

> 16bit BDE functionality is no longer being actively supported
> by dang near anyone these days, so even if the 16bit
> architecture was 10 times faster it doesn't really matter.

I want to see the day to come, when operational speed, response times
etc. no more have any substantial meaning with computing:)

Let's say you bring a new 'fast, full 32-bit version' of your app to
your client. And that turns out to be 40..50% slower than the 16-bit
oldie. It usually matters, if the previous 3 second response time
grew to 6 seconds.

It can mean that you even have to postpone all your 32-bit product
versions, and instead start to consider and implement some totally
different database solutions.
It usually means extra burning of somone's money. You are lucky if
the client agrees that he/she of course is the object to handle
these bills.

Markku Nevalainen

Re:Bench Test with BDE 16b and BDE 32b ?!


If your client was using the 16bit version of your software
and was not unhappy with it, why change to 32bit at all?

The client may think that the extra functionality that you
*may* be able to provide with the 32bit application offsets
the speed/performance penalty incurred by the change
from 16 to 32 bits.

BTW, these figures were quoted going from 16 to 32 bit
BDE.  The BDE, for me, is simply not good enough for
any client.  Ditch the BDE and use something altoghether
better, like DBISAM, GMDAO/ADO, ADOExpress,
InterbaseExpress or IBObjects.

I don't notice any speed difference between 16 bit DBISAM
and 32 bit DBISAM.  They're both reeeeeeeeeeeeally fast.

Graham Wood - gdW fleetWare.

Quote
Markku Nevalainen <m...@iki.fi> wrote in message news:37F65428.6C9F@iki.fi...
> I want to see the day to come, when operational speed, response times
> etc. no more have any substantial meaning with computing:)

> Let's say you bring a new 'fast, full 32-bit version' of your app to
> your client. And that turns out to be 40..50% slower than the 16-bit
> oldie. It usually matters, if the previous 3 second response time
> grew to 6 seconds.

> It can mean that you even have to postpone all your 32-bit product
> versions, and instead start to consider and implement some totally
> different database solutions.
> It usually means extra burning of somone's money. You are lucky if
> the client agrees that he/she of course is the object to handle
> these bills.

> Markku Nevalainen

Re:Bench Test with BDE 16b and BDE 32b ?!


Quote
Graham Wood wrote:

> If your client was using the 16bit version of your software
> and was not unhappy with it, why change to 32bit at all?

You must have heard about internet connections, linking with MS
databases, Office products etc. These all are easier to do with
newer Delphi versions.

Quote
> The client may think that the extra functionality that you
> *may* be able to provide with the 32bit application offsets
> the speed/performance penalty incurred by the change
> from 16 to 32 bits.

That must have been a quote right from Microsofts marketing manual:)
Who cares if new 32-bit office products are slower and buggier
than the old ones, if you just get new functionality.
But with busy invoicing apps, POS apps etc, you usually can't
afford to release 50% slower apps, even if they carry nice 32-bit
label on them.

I kind of like the simple, clear idea that if you change either your
hardware or software from 8-bit to 16-bit, again from 16-bit to
32-bit, and next year up to 64-bit, on every step you get faster,
or at least not slower products as you had earlier.

Markku Nevalainen

Other Threads