Rob,

<< No.  We customers pay for them. >>

Yes, indirectly.  However, you don't make the day to day decisions about how
Elevate Software is run, do you ?

<< I have a support question.  Why is EDB insert speed so slow?  How can it
be sped up to match the competition? >>

As I said before, I won't discuss such benchmarks any further because they
are very one-dimensional and don't necessarily reflect the performance one
would see in the real world.  All one has to do is look at the Paradox/BDE
results of that benchmark to understand that it conveys a limited amount of
information about actual performance (hint: Exclusive:=True).

Also, this is the DBISAM newsgroup.  If you have an EDB support question,
please post it in the appropriate newsgroup.

--
Tim Young
Elevate Software
www.elevatesoft.com

My question was also about DBISAM.  Unfortunately, lots of people look at simple
benchmarks to compare.  It's a pretty common topic for any database.  I don't think
ignoring them will help.  I would suggest some sort of batch mode.  Then everyone will
shut up.

Another suggestion.  Sell a web framework based of this website.  This site design blows
away the competition and it all runs on DBISAM if I remember.

As for someones question about the Paradox indexes, I think they are called clustered
indexes and thats why they are so small. No idea how they work but Paradox slows to a
crawl on big tables with multi-user.

Rob

"Tim Young [Elevate Software]" wrote:

As I said before, I won't discuss such benchmarks any further because they
are very one-dimensional and don't necessarily reflect the performance one
would see in the real world.  All one has to do is look at the Paradox/BDE
results of that benchmark to understand that it conveys a limited amount of
information about actual performance (hint: Exclusive:=True).

Also, this is the DBISAM newsgroup.  If you have an EDB support question,
please post it in the appropriate newsgroup.

--
Tim Young
Elevate Software
www.elevatesoft.com

Rob,

<< My question was also about DBISAM.  Unfortunately, lots of people look at
simple benchmarks to compare.  It's a pretty common topic for any database.
I don't think ignoring them will help.  I would suggest some sort of batch
mode.  Then everyone will shut up. >>

Both DBISAM and ElevateDB use transactions for "batching", while NexusDB
uses a specific "batch" mode.  The BDE/Paradox has neither, so the benchmark
author just turned on Exclusive:=True, which doesn't really reflect the
reality of a multi-user shared database.  The issue with the DBISAM
performance versus the ElevateDB performance is a design issue with
ElevateDB that makes it slightly slower than DBISAM under Win32, and this
has already been addressed for EDB 2.03, resulting in the performance of EDB
being about 1000 rows per second faster than DBISAM on that particular
benchmark.  However, again, the point of not discussing these benchmarks is
because they take forever to explain all of the little issues and work out
the hows and whys, and that time is better spent on improving the product.
To just assume that the reason why we don't want to discuss such benchmarks
is because we are ignoring the results is not correct.  I spent a better
part of a month in February working on design changes to EDB to get the
performance above DBISAM in this particular benchmark for EDB 2.03.  You
have to remember that the same EDB code that runs under Win32 has to also
run under .NET managed code.  This limits what we can do with EDB to some
extent, especially with how we use pointers and direct memory manipulation.
The DBISAM, the BDE, and NexusDB do not have these limitations placed on
them, nor will our Enterprise Server version of EDB.

<< Another suggestion.  Sell a web framework based of this website.  This
site design blows away the competition and it all runs on DBISAM if I
remember. >>

Yes.  Unfortunately it would be Herculean task to get such a product put
together.  However, I'll see about getting the source code posted so
everyone can see how it works.  Our Internet server is actually just one
component that handles all SMTP, POP3, NNTP, and HTTP services.

--
Tim Young
Elevate Software
www.elevatesoft.com

Rob wrote:

>As for someones question about the Paradox indexes, I think they are called clustered
>indexes and thats why they are so small.

... hmm, this thread seems to have some life yet.  

I don't think clustered indexes are the key in here. According to Wikipedia clustered indexes are more like the cutting edge, "far more
sophisticated" than non clustered indexes. http://en.wikipedia.org/wiki/Index_(database)
Here's a longer story about Clustered and Non-Clustered Indexes when used with MS SQL Server
http://www.sql-server-performance.com/articles/per/index_data_structures_p5.aspx

As far as I can see BDE/Paradox does not use clustered indexing in that forbidden benchmark. Clustered indexes would mean that those
Paradox records should be physically organized according to the clustered index field, but they are not.

> No idea how they work but Paradox slows to acrawl on big tables with multi-user.

We did not experience that in the old days. Competitor's VB + Access database apps would freeze with 3..4 users, but BDE/Paradox could
easily handle even 20 or more simultaneous users. Of course the apps were lighter also than now a days.

I am a bit shy to respond to Tim's message directly as this is a closed thread anyway But it is true that if you turn Exclusive=False with
BDE/Paradox then the processing time with it increases by factor of 4. Yet it faster than DBISAM, but the overall winner in this particular
test would now be Nexus.

That Exclusive thing made me to wonder one thing. Within DBISAM/ElevateDB architecture, the SERVER process also in C/S installation
has all the time to take in to account that there may be someone else accessing the DBISAM database. By using the traditional File Share
mode. Wouldn't that kind of extra check loop add some extra slowing overhead?

If it does slow down the SERVER process, then maybe some there could be new setting that says that now the SERVER has exclusive
ownerships to the database, and it would increase the speed. Then it would be up to the application developer to ensure that no one else
would have access to those files. But you get a significant performance boost, either whole time, or maybe only when you execute some
heavy batches.
Stan

Stan,

<< I am a bit shy to respond to Tim's message directly as this is a closed
thread anyway But it is true that if you turn Exclusive=False with
BDE/Paradox then the processing time with it increases by factor of 4. Yet
it faster than DBISAM, but the overall winner in this particular test would
now be Nexus. >>

That's not what I saw here with the BDE.  The BDE slowed down to 5000
rows/sec with LOCAL SHARE turned on and Exclusive=False, which is a true
multi-user test.  With the EDB 2.03 performance improvements, I'm seeing
9300-9600 rows/sec with DBISAM, and 10000-10400 rows/sec with EDB
(transaction size of 15000 rows).

<< That Exclusive thing made me to wonder one thing. Within DBISAM/ElevateDB
architecture, the SERVER process also in C/S installation has all the time
to take in to account that there may be someone else accessing the DBISAM
database. By using the traditional File Share mode. Wouldn't that kind of
extra check loop add some extra slowing overhead?

If it does slow down the SERVER process, then maybe some there could be new
setting that says that now the SERVER has exclusive ownerships to the
database, and it would increase the speed. Then it would be up to the
application developer to ensure that no one else would have access to those
files. But you get a significant performance boost, either whole time, or
maybe only when you execute some heavy batches. >>

The issue is the design - you can't design an engine to work both ways.
Even if you give it exclusive access to the databases, it still uses a
buffering, locking, and change detection/concurrency design that is based
upon multi-user file-sharing.  That's why I indicated that these tests are
less than illuminating.  You're comparing an engine (EDB) that is designed
to run in 3 different modes (local/file-share/C-S) and natively under
Win32/WinCE/.NET (and soon Linux) against engines that are designed to be
one and only one thing.  That is the reason why we're planning to do a
separate Enterprise Server version of EDB.

Now, please, will everyone respect my wishes and let this thread die a
natural death ?

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:1FF8BB13-8D92-4CE0-B777-7FA655406D94@news.elevatesoft.com...
>
> Now, please, will everyone respect my wishes and let this thread die a
> natural death ?
>

No just one little squeak from me DBIsam is the dogs bollocks of all
databases I have most so I should know. Benchmarks depend whos
bench the test is on. A real life test New Years eve in a Cab Office
running a DBIsam Server 240 cabs on the road 15 telephonists the
phones never ever stopped for 9 hours solid. Each telephonist was
at a terminal and 10 controllers were at terminals also during all the
chaos account customers linked in via online connections to book.
I can only guess that all in all with 240 cars + 15 phones + 10 controls
total 265 that maybe 3/4 online guys it would = around the 270 mark
all connected and putting in details. The phone guys/dolls taking calls
the controllers sending out the details the drivers sending back info
and online customers inputing data, oh! the whole thing has never ever
crashed except in a power outage but that was not our or DBISam's
fault. It was not even my rock solid coding or anti memory leak crusade.
Topaz and Delphi failed Halcyon and Delphi failed Advantage and Delphi
failed Paradox and Delphi failed jet and all sorts of stuff I have bought
and
long forgotten. So tell them take their benchmarks to the real world DBISam
works. I just thought on dont forget as well as the 270 connections the
accounts department working in the background and all the other office
duties. Trevor's well written account code remodelled took care of that.

Rita

"Tim Young [Elevate Software]" wrote:

>That's not what I saw here with the BDE.  The BDE slowed down to 5000
>rows/sec with LOCAL SHARE turned on and Exclusive=False,

I have all the time ran all the BDE tests with LOCAL SHARE=True. My BDE version is as old as 5.1, and the computer is 3 years old  3.5
Mhz machine. My intention is not to keep re-posting more and more results, but with BDE Exclusive=False setting turned on, here are my
final results:

50.000 records
--------------
BDE/Paradox 5.0   Elapsed: 2,4 sec,  21 053 Rcds/Sec
NexusDb 2.072  Elapsed: 1,4 sec,  36 364 Rcds/Sec
DBISAM 3.30   Elapsed: 3,8 sec, 13 168 Rcds/Sec
ElevateDb 2.01 Elapsed: 6,2 sec,  8 081 Rcds/Sec

> 9300-9600 rows/sec with DBISAM, and 10000-10400 rows/sec with EDB
> (transaction size of 15000 rows).

That sounds good! Those new numbers are now much more on the level.

> You're comparing an engine (EDB) that is designed
> to run in 3 different modes (local/file-share/C-S) and natively under
> Win32/WinCE/.NET (and soon Linux)

I completely understand this. Your company has set their targets, and they are set to be there. Yet I want to say that currently there is no
work-around code for DBISAM/ElevateDB to make for instance this kind of insertion task to perform more quickly.  

We have got calls about occasional application slow downs that can't be solved, no known reason. There's a good chance those cases have
*nothing to do woth this thread*.   There's no catastrophe or anything either, and we highly, highly appreciate the stableness of Elevate
databases.
We just do not want to wake up some morning and find that yes, now we are facing a bad one with some bigger customer. As a developer
one just would like to find reasons, and that was the motivation to start running any of these comparisons.

> and let this thread die a natural death ?

Is there such a thing? Once the tooth paste has come out you can't completely stuff it backBut fortunately we can encapsulate things,
for unknown periods. Forcing to continue this thread will not lead to any quick overnight changes, and currently we can live with that.  
Thanks for everybody.
Stan

Stan,

<< I have all the time ran all the BDE tests with LOCAL SHARE=True. My BDE
version is as old as 5.1, and the computer is 3 years old  3.5 Mhz machine.
My intention is not to keep re-posting more and more results, but with BDE
Exclusive=False setting turned on, here are my final results: >>

You should double-check about the LOCAL SHARE setting and the Exclusive
property.  There's no way that the BDE is getting 21,000+ rows per second
without it having exclusive access to the data.  It's just not possible due
to the disk I/O required.  An easy way to check is to watch the file sizes
as the benchmark executes.

<< I completely understand this. Your company has set their targets, and
they are set to be there. Yet I want to say that currently there is no
work-around code for DBISAM/ElevateDB to make for instance this kind of
insertion task to perform more quickly. >>

And what relevance does inserting 200,000+ rows in one sitting have to your
application ?  Batch inserts of rows has absolutely no bearing on how your
application will perform in a multi-user setting with singleton or small
batches of inserts/updates/deletes being executed.  That is, unless you're
actually needing to insert hundreds of thousands of rows in batches.  By
your very sparse description of your application, I don't see this as being
the case.  You seem to be extrapolating this batch insert performance to
your application when there is no direct relationship between the two.
There are all sorts of other issues that get in the way of multi-user
performance besides the raw execution time of an INSERT operation.  For
starters, there's a lot more disk I/O involved in a multi-user scenario.

<< We have got calls about occasional application slow downs that can't be
solved, no known reason. >>

And again, did you ever send us an email or call us to figure out what the
problem is ?  It could be a simple matter of an un-optimized filter or query
that is causing a table scan on a large table, thus causing writers to wait
for the scan because of a read lock on the table.  This is the same with any
database engine that uses locking for enforcing concurrency - some will
automatically use a table-wide read lock, like DBISAM and EDB, because they
know that they will be scanning the entire table, whereas others will use
row read locks until the locks reach a certain level, and then promote them
to a table-wide read lock.

--
Tim Young
Elevate Software
www.elevatesoft.com

Rita,

<< No just one little squeak from me DBIsam is the dogs bollocks of all
databases I have most so I should know. Benchmarks depend whos bench the
test is on. A real life test New Years eve in a Cab Office running a DBIsam
Server 240 cabs on the road 15 telephonists the phones never ever stopped
for 9 hours solid. >>

Exactly, thank you.  We've been running our entire business on DBISAM
for 10 years, including the web site, servicing thousands of customers.

--
Tim Young
Elevate Software
www.elevatesoft.com

I've seen that Tim is right on here.  If you are inserting 8000 recs/sec then you need to
be using Oracle or something very heavy.  We're talking server farms.  I'm happy with 100
recs/sec if the db is reliable and easy to use.  We also forget that Elevate products are
fire and forget, multi-user fileserver or CS, no problem.  That's worth a lot.

PS. Please release your business/web framework!  Its lovely.

Rob


Stan wrote:

50.000 records
--------------
BDE/Paradox 5.0   Elapsed: 2,4 sec,  21 053 Rcds/Sec
NexusDb 2.072  Elapsed: 1,4 sec,  36 364 Rcds/Sec
DBISAM 3.30   Elapsed: 3,8 sec, 13 168 Rcds/Sec
ElevateDb 2.01 Elapsed: 6,2 sec,  8 081 Rcds/Sec