If I switch to ElevateDb from DBISAM 4, am I going to see much speed
improvements? What operations of ElevateDb is faster than DBISAM 4? Has
anyone  done a speed comparison?
TIA

Dave

Dave,

<< If I switch to ElevateDb from DBISAM 4, am I going to see much speed
improvements? What operations of ElevateDb is faster than DBISAM 4? Has
anyone  done a speed comparison? >>

Both reads, and writes, especially with tables with a lot of indexes, should
be quite a bit faster in EDB than in DBISAM.  A lot of this is due to the
new index format, which uses a faster, automatic compression method that
doesn't require as much overhead and the removal of the index statistics,
which resulted in quite a bit of savings in terms of the number of index
pages needing updating for each row update.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Dave,
>
> << If I switch to ElevateDb from DBISAM 4, am I going to see much speed
> improvements? What operations of ElevateDb is faster than DBISAM 4? Has
> anyone  done a speed comparison? >>
>
> Both reads, and writes, especially with tables with a lot of indexes, should
> be quite a bit faster in EDB than in DBISAM.  A lot of this is due to the
> new index format, which uses a faster, automatic compression method that
> doesn't require as much overhead and the removal of the index statistics,
> which resulted in quite a bit of savings in terms of the number of index
> pages needing updating for each row update.
>

That sounds good in theory, but have you been able to benchmark this?
I've found DBISAM is still considerably faster at inserting records
(with transactions) and traversing tables. But EDB is faster at building
indexes.

Dave

Dave Harrison wrote:
> Tim Young [Elevate Software] wrote:
>
>> Dave,
>>
>> << If I switch to ElevateDb from DBISAM 4, am I going to see much
>> speed improvements? What operations of ElevateDb is faster than DBISAM
>> 4? Has anyone  done a speed comparison? >>
>>
>> Both reads, and writes, especially with tables with a lot of indexes,
>> should be quite a bit faster in EDB than in DBISAM.  A lot of this is
>> due to the new index format, which uses a faster, automatic
>> compression method that doesn't require as much overhead and the
>> removal of the index statistics, which resulted in quite a bit of
>> savings in terms of the number of index pages needing updating for
>> each row update.
>>
>
> That sounds good in theory, but have you been able to benchmark this?
> I've found DBISAM is still considerably faster at inserting records
> (with transactions) and traversing tables. But EDB is faster at building
> indexes.
>
> Dave

So has anyone written a benchmark program that demonstrates ElevateDb is
faster than DBISAM at inserting records?

TIA
Dave

Dave,

<< That sounds good in theory, but have you been able to benchmark this?
I've found DBISAM is still considerably faster at inserting records (with
transactions) and traversing tables. But EDB is faster at building indexes.
>>

I can see it with my eyes.  Take a query in DBISAM, run it in EDB, and it
should run faster, excepting the issue that we discussed with live queries.
If it doesn't, then there's an issue with EDB.

As far as indexes are concerned, insert speed is almost directly
proportional to how fast the indexes can be updated (row updates are so
negligible as to be a non-issue), therefore faster index updates in EDB will
translate to faster insert speeds.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Dave,
>
> << That sounds good in theory, but have you been able to benchmark this?
> I've found DBISAM is still considerably faster at inserting records (with
> transactions) and traversing tables. But EDB is faster at building indexes.
>  >>
>
> I can see it with my eyes.  

I don't see so good any more and don't trust my eyes. A timer is much
better.

> Take a query in DBISAM, run it in EDB, and it
> should run faster, excepting the issue that we discussed with live queries.
> If it doesn't, then there's an issue with EDB.

Well, I hate to break this to you, but in the rudimentary tests I've
done with Select statements, static DBISAM queries are still faster than
EDB static queries using the same data and indexes. (I'm comparing the
same SQL using DBSys and EDBMgr on same table structures and same data -
I assume these timings are accurate). The table has 16 million rows and
3 compound indexes. DBISAM speed is around 0.188 seconds and EDB around
0.406 seconds. 6913 rows are returned. I've done several queries with
and without sorting, and DBISAM is usually faster.

Now I haven't done any formal testing by writing my own program with
generated test data, but that is probably the next step.

> As far as indexes are concerned, insert speed is almost directly
> proportional to how fast the indexes can be updated (row updates are so
> negligible as to be a non-issue), therefore faster index updates in EDB will
> translate to faster insert speeds.

Yes, that's what I was hoping for too. But I'm still finding DBISAM
faster at inserting data with the same record & index structure by about
40%. I was wondering if anyone has done some side by side benchmarking
to show that EDB is faster than DBISAM at inserting records and with
queries in general. I had assumed since DBISAM had been benchmarked a
lot over the years, the same benchmarks would have been converted to EDB
so you could do a side by side comparison.

Dave

Dave,

<< I don't see so good any more and don't trust my eyes. A timer is much
better. >>

 Actually, what I meant was that I can see it in the EDB Manager and
DBSYS, which report the execution times.

<< Well, I hate to break this to you, but in the rudimentary tests I've done
with Select statements, static DBISAM queries are still faster than EDB
static queries using the same data and indexes. (I'm comparing the same SQL
using DBSys and EDBMgr on same table structures and same data - I assume
these timings are accurate). The table has 16 million rows and 3 compound
indexes. DBISAM speed is around 0.188 seconds and EDB around 0.406 seconds.
6913 rows are returned. I've done several queries with and without sorting,
and DBISAM is usually faster. >>

Are you using encrypted tables ?  If so, then EDB automatically encrypts the
result set, resulting in slower temporary table building times, while DBISAM
requires the ENCRYPTED WITH clause in order to do so.

<< Yes, that's what I was hoping for too. But I'm still finding DBISAM
faster at inserting data with the same record & index structure by about
40%. >>

Please send me what you're using.  My guess is that there is a reasonable
explanation for this that isn't necessarily immediately obvious.  It may, as
I noted above, have something to do with the encryption.

<< I was wondering if anyone has done some side by side benchmarking to show
that EDB is faster than DBISAM at inserting records and with queries in
general. I had assumed since DBISAM had been benchmarked a lot over the
years, the same benchmarks would have been converted to EDB so you could do
a side by side comparison. >>

We stopped doing formal benchmarks because they simply stirred up a hornet's
nest and were pretty much meaningless after that point.   We do, however,
have performance tests in our automated testing that both DBISAM and EDB
have to meet for every single build in order to be released.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Dave,
>
> << I don't see so good any more and don't trust my eyes. A timer is much
> better. >>
>
>  Actually, what I meant was that I can see it in the EDB Manager and
> DBSYS, which report the execution times.

Ok. I thought you might be eye-balling it.

>
> << Well, I hate to break this to you, but in the rudimentary tests I've done
> with Select statements, static DBISAM queries are still faster than EDB
> static queries using the same data and indexes. (I'm comparing the same SQL
> using DBSys and EDBMgr on same table structures and same data - I assume
> these timings are accurate). The table has 16 million rows and 3 compound
> indexes. DBISAM speed is around 0.188 seconds and EDB around 0.406 seconds.
> 6913 rows are returned. I've done several queries with and without sorting,
> and DBISAM is usually faster. >>
>
> Are you using encrypted tables ?  If so, then EDB automatically encrypts the
> result set, resulting in slower temporary table building times, while DBISAM
> requires the ENCRYPTED WITH clause in order to do so.

Not using encryption.

>
> << Yes, that's what I was hoping for too. But I'm still finding DBISAM
> faster at inserting data with the same record & index structure by about
> 40%. >>
>
> Please send me what you're using.  My guess is that there is a reasonable
> explanation for this that isn't necessarily immediately obvious.  It may, as
> I noted above, have something to do with the encryption.

I'll finish my benchmark program and submit it in the binaries. It will
take a couple of days.

>
> << I was wondering if anyone has done some side by side benchmarking to show
> that EDB is faster than DBISAM at inserting records and with queries in
> general. I had assumed since DBISAM had been benchmarked a lot over the
> years, the same benchmarks would have been converted to EDB so you could do
> a side by side comparison. >>
>
> We stopped doing formal benchmarks because they simply stirred up a hornet's
> nest and were pretty much meaningless after that point.   We do, however,
> have performance tests in our automated testing that both DBISAM and EDB
> have to meet for every single build in order to be released.

I just meant publishing benchmarks comparing DBISAM vs EDB. I don't
think that would stir up a hornets nest would it? Or would the DBISAM
zealots take on the EDB fanatics?

Dave

Dave,

<< Not using encryption. >>

Would it be possible to get the query and DBISAM tables ?

<< I'll finish my benchmark program and submit it in the binaries. It will
take a couple of days. >>

Thanks.

<< I just meant publishing benchmarks comparing DBISAM vs EDB. I don't think
that would stir up a hornets nest would it? Or would the DBISAM zealots take
on the EDB fanatics? >>

No, I don't think that would be a problem.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Dave,
>
> << Not using encryption. >>
>
> Would it be possible to get the query and DBISAM tables ?
>
> << I'll finish my benchmark program and submit it in the binaries. It will
> take a couple of days. >>
>
> Thanks.
>
> << I just meant publishing benchmarks comparing DBISAM vs EDB. I don't think
> that would stir up a hornets nest would it? Or would the DBISAM zealots take
> on the EDB fanatics? >>
>
> No, I don't think that would be a problem.
>

Tim,
   I've uploaded the benchmark program to the binaries. EDB did better
when I decreased the transaction size to 100 rows instead of using 1500
or 15000. It was about twice as fast as DBISAM when tuned correctly.

Dave