Hi folks,

I just had to make my own benchmarks on this:
Table structure:

CREATE TABLE TEST (TEST_ID numeric(7) not null,
test_text varchar(30),
constraint pk_test primary key(test_id)
);

Insert with TIBOQuery (TDataset) traditional Append, Post:
----------------------------------------------------------

1000 Records local IB Win2k Pentium III 800Mhz, 256MB RAM: 1 second
1000 Records remote IB on Suse Linux 6.4 PII 350MhZ 256MB RAM: 2 seconds

Insert using T_IBQuery Prepared Insert statement with Params
------------------------------------------------------------
20000 Records local IB Win2k Pentium III 800Mhz, 256MB RAM: 3.5 seconds
20000 Records remote IB on Suse Linux 6.4 PII 350MhZ 256MB RAM: 10
seconds

Times were measured just before calling TIB_TransAction.Commit;

Never got such times when running oracle on those boxes !

VERY VERY NICE - IB with IBO rock'N'rolls! I am really pleased with the
results!

--
Christian Kaas mailto:christian@...
Client/Server/Internet/Multitier development
http://www.ckaas.de

> -----Ursprungliche Nachricht-----
> Von: Jason Wharton [mailto:jwharton@...]
> Gesendet: Montag, 8. Januar 2001 22:27
> An: IBObjects@egroups.com
> Betreff: Re: [IBO] Interbase,Advantage,Paradox
>
>
> > > 1. If it's performance you are seeking, there is NO WAY
> you should be
> > > using TIBOTable for an executable process. Put this
> statement into a
> > > TIBOQuery...
> >
> > Would a TIB_DSQL component not perform better for bulk
> inserts since it
> does
> > not have the extra baggage associated with the TIBOQuery component ?
>
> Yes, this is the best component to use for batch inserts.
>
> > > 3. Forced writes will slow things down (as observed) but
> if you have a
> > > fragile network environment or users who habitually
> terminate a database
> > > session by switching the computer off, it's worth the cost.
> >
> > Really ? I have client sites where the users habitually terminate a
> database
> > session by switching the computer off. I have been trying
> to break them of
> > this habit for years, but without success. I was under the
> impression that
> > IB would solve this problem due to it's C/S design. What
> kind of problems
> > can I expect when this happens ? I realize that any pending
> transactions
> > will not be committed, but please tell me my database will
> still be intact
> ?
>
> You are safe with InterBase. The only reason you want forced
> writes on is if
> you SERVER is ever susceptible to a power failure or your OS
> install is in
> flaky condition.
>
> What I usually do is leave forced writes on and when I am
> doing some hard
> crunching in a batch job I turn them off temporarily and put
> them back on
> again when I am done. I usually always have a backup prior to
> doing major
> crunch updates/loads to my database in case something does go wrong.
>
> A failed client will not adversely affect the server's data integrity,
> period. That's client server.
>
> > > As a general comment, it doesn't make sense to force
> InterBase to behave
> > > like a file-based database (which it's not) and then expect it to
> compare
> > > favourably with file-based databases, performance-wise.
> The kind of
> > > "benchmark" you are trying to do is rather silly, for
> example, because
> one
> > > would never be inserting 1000 records from a table interface. The
> Insert
> > > and Append methods are intended for one-by-one manual inserts.
> >
> > I agree that this is a silly test, but it is probably one
> of the first
> tests
> > that every BDE to IB convert tries. The table interface gives the
> developer
> > the warm fuzzies they had with the BDE TTable component and
> is a natural
> > selection.
>
> Get over it!
>
> > > A further comment is this. Client/Server databases
> aren't intended for
> > > desktop use. If speed is your only criterion then stay
> with the desktop
> > > database. The transaction model is meant to preserve
> data integrity in
> a
> > > multi-user environment. It would be surprising if there
> were no cost to
> > > that. If your single-user app is getting broken by user
> behavior under
> > > Paradox, it won't get better by switching to another database.
> >
> > I would imagine that the majority of people migrating from
> Paradox to IB
> are
> > switching for the improved multi-user support, but still
> need to support a
> > single user environment. I have found that IB performs
> quite well in a
> > single user environment as long as the app and database are
> designed to
> take
> > advantage of IB's strengths. Reads, inserts and updates all
> appear to be
> > much faster. Could you elaborate on where IB might be
> slower ? This could
> be
> > very helpful to newcomers like myself.
>
> IB will be slower than paradox if you are not taking
> advantage of any of the
> additional features and capabilities that InterBase has. With
> hardware ever
> increasing I really don't think this is a significant performance gap.
> InterBase is so efficient that it can and will do a good job
> in a single
> user environment.
>
> FWIW,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
>
>
>