Robust Single File database - updated benchmark results
Ian Roberts
(adding a Locate procedure and two new database engines, TurboDB and
Accuracer). I also increased the number of records to 1 million in order to
achive better accuracy. I believe some people would be interested in
seeing my results. I will likely add NexusDB to this table later this week.
Ian Roberts
-------------------
Result table. Best viewed with courrier
ABS EASY ADS DISQL DBISAM TURBODB
ACC
Single file Yes Yes No Yes No Yes
Yes
Standard TTable commands Yes Yes Yes No Yes Yes
Yes
Without Index
Creating 1,000,000 records 46.9 773.2 54.4 6.1 31.4 25.7
190.0
Reading all data 5.5 163.3 7.5 1.6 4.3 5.5
9.0
Rewriting records 24.5 593.8 38.4 4.6 15.7 47.0
158.8
Locate (50 times/no index) 68.7 713.2 14.3 11.5 234.0 129.3
119.5
Create index 169.7 1118.1 1.0 6.4 6.7 8.4
257.2
Reading all data 9.7 256.6 15.4 3.4 5.2 10.0
34.3
Rewriting records 119.6 764.2 41.6 6.5 16.6 46.6
229.8
Locate (5000 times) 0.7 3.5 0.3 0.1 0.5 46.0
0.8
Filter 1 of 10 records 0.0 20.0 0.0 0.0 5.0 7.0
29.6
EXE increase 808K 577K 119K 304K 994K 1027K
969K
DLL size - -
13K - - - -
Size of TEST DB (with index) 89MB 140MB 55MB 41MB 103MB 48MB
164Mb
ABS - ABSOLUTE DATABASE v5.11
EASY - EASY TABLE v6.1
ADS - Advantage Local Server v8.1
DISKL - DISQLite3 v3.3.8
DBISAM - DBISAM v4.25
TURBODB - TurboDB 5.09
ACC - ACCURACER v4.1
Ian Roberts
Ian
-------------
Result table. Best viewed with courrier
ABS EASY ADS DISQ DBISAM TURBO ACC
Single file Yes Yes No Yes No Yes Yes
Standard TTable commands Yes Yes Yes No Yes Yes Yes
Without Index
Creating 1,000,000 records 46.9 773.2 54.4 6.1 31.4 25.7 190.0
Reading all data 5.5 163.3 7.5 1.6 4.3 5.5 9.0
Rewriting records 24.5 593.8 38.4 4.6 15.7 47.0 158.8
Locate (50 times/no index) 68.7 713.2 14.3 11.5 234.0 129.3 213.1
Create index 169.7 1118.1 1.0 6.4 6.7 8.4 298.3
Reading all data 9.7 256.6 15.4 3.4 5.2 10.0 39.1
Rewriting records 119.6 764.2 41.6 6.5 16.6 46.6 229.8
Locate (5000 times) 0.7 3.5 0.3 0.1 0.5 46.0 0.8
Filter 1 of 10 records 0.0 20.0 0.0 0.0 5.0 7.0 33.1
EXE increase 808K 577K 119K 304K 994K 1027K 969K
DLL size - - 2113K - - - -
Size of TEST DB (with index) 89MB 140MB 55MB 41MB 103MB 48MB 164Mb
ABS - ABSOLUTE DATABASE v5.11
EASY - EASY TABLE v6.1
ADS - Advantage Local Server v8.1
DISQ - DISQLite3 v3.3.8
DBISAM - DBISAM v4.25
TURBO - TurboDB 5.09
ACC - ACCURACER v4.1
Leo Martin
Hello, Ian.
It would be nice if you will upload source code of your test.
I have tried to send my comments about test project you have sent to us 10 January 2007, but failed - got reply from Yahoo mail server that account does not work.
Your test for Accuracer was not correct. You have used VARCHAR field type for string fields which is not supported by most of other database engines. Type ftString in Accuracer is VARCHAR, which typically works much slower then ftFixedChar (CHAR). It gives advantages only when most of values are empty strings or very short strings. It is not correct to compare VARCHAR performance of one database with CHAR performance of another database.
Best regards,
Leo Martin,
Lead Developer,
AidAim Software mailto:sup...@aidaim.com
Eivind Bakkestuen
> (adding a Locate procedure and two new database engines, TurboDB and
> Accuracer). I also increased the number of records to 1 million in
> order to achive better accuracy. I believe some people would be
> interested in seeing my results. I will likely add NexusDB to this
> table later this week.
I don't see this anywhere in your benchmark description, and I believe it is
important for the correct evaluation of the results.
Is the focus of the test using 100% BDE compatible source, or is it making
each engine work as fast as possible?
--
Eivind Bakkestuen
Nexus Database Systems Pty Ltd
Jim Davis
Ian Roberts
I just sent you a message with the source code allowing you to further check
for problems in the benchmark. The fast that for all other database engine
ftStrings means a string field of fixed length, but that for Accuracer it
means a variable length is something that I didn't know. I ran the test
again on Accuracer changing the field type to ftFixedChar and updated the
table (see below).
Ian
Result table. Best viewed with courrier
ABS EASY ADS DISQ DBISAM TURBO ACC
Single file Yes Yes No Yes No Yes Yes
Standard TTable commands Yes Yes Yes No Yes Yes Yes
Without Index
Creating 1,000,000 records 46.9 773.2 54.4 6.1 31.4 25.7 75.4
Reading all data 5.5 163.3 7.5 1.6 4.3 5.5 5.8
Rewriting records 24.5 593.8 38.4 4.6 15.7 47.0 34.6
Locate (50 times/no index) 68.7 713.2 14.3 11.5 234.0 129.3 58.1
Create index 169.7 1118.1 1.0 6.4 6.7 8.4 139.7
Reading all data 9.7 256.6 15.4 3.4 5.2 10.0 23.1
Rewriting records 119.6 764.2 41.6 6.5 16.6 46.6 77.0
Locate (5000 times) 0.7 3.5 0.3 0.1 0.5 46.0 0.6
Filter 1 of 10 records 0.0 20.0 0.0 0.0 5.0 7.0 20.1
EXE increase 808K 577K 119K 304K 994K 1027K 969K
DLL size - - 2113K - - - -
Size of TEST DB (with index) 89MB 140MB 55MB 41MB 103MB 48MB 105Mb
"Leo Martin" <sup...@aidaim.com> wrote in message
news:45b5...@newsgroups.borland.com...
Ian Roberts
message news:45b53c65$1...@newsgroups.borland.com...
> Is the focus of the test using 100% BDE compatible source, or is it making
> each engine work as fast as possible?
Except for DISQLite3, which does not support BDE compatible commands, I have
used 100% BDE compatible source for all other database engines (in fact, the
source code is almost identical). The only difference is the use of
StartTransaction and Commit for those engines supporting it. In the case of
DISQLite3, I made sure the procedures used were functionally similar to
those used for other engines.
If a vendor wants to create an optimized version to see how fast one can go
when using engine specific commands, they are free to do so, but I also want
to present results one would get with standard TTable commands. (I am not
an expert in all database engines, so creating an optimized version for all
engines would be difficult for me without investing a lot of time).
Also, one thing I should say is that all tests were made by setting the
Table.Exclusive property to True (maybe I should run other tests with
TTable.exclusive set to false), but it is a choice I made.
Ian
Hannes Danzl[NDD]
Some observations:
> Creating 1,000,000 records 46.9 773.2 54.4 6.1 31.4 25.7 190.0
This is heavily depending on several things:
* db write mode (cached, writethrough)
* record block sizes
* use of transactions
* database cache size
* and even disk fragmentation
Every database has it's own default settings that are not necessarily (or in
you case almost surely not) the best environment for a certain project. You
always need to understand the settings of a db engine and use them to your
advantage, otherwise you end up like driving a car with handbrakes on.
> Reading all data 5.5 163.3 7.5 1.6 4.3 5.5 9.0
again, db cache will heavily influence it. essentially with just 1mio records
though the full database should be in memory and thus it's merely reading data
from memory. As such the test is in itself pretty useless except you ever
intend to iterate a NEWLY created table in an unordered way.
> Rewriting records 24.5 593.8 38.4 4.6 15.7 47.0 158.8
see comments on creating. Here even more things com in play as some dbs are
"intelligently" reusing space and some have settings for it's aggressivity.
> Locate (50 times/no index) 68.7 713.2 14.3 11.5 234.0 129.3 119.5
locate with no index is a pure iteration, as such it's again very heavily
cache depending.
> Create index 169.7 1118.1 1.0 6.4 6.7 8.4
cache applies again, also index settings like locales (trasnformations!),
index blocksize and last but not least the data. An index is usually a certain
tree structure and the pre-order of the data defines how deep a tree goes or
how often it has to be rebalanced each of which can heavily change
performance. I've for example seen benchmarks before that where creating
millions of RANDOM rows, each time different for different databases and then
trying to compare. This is NOT a proper to compare indexing and search/locate
time. Even if the data is fixed it doesn't necessarily give you any indication
on how well the engine will perform in real life, due to the different
structure and algorithms used. Some are e.g. blazingly fast and blow
everything as long as the *whole* tree fits into memory. Once you hit that the
come to crawl and essnetially render the engine unfit for any larger than
memory database.
> Filter 1 of 10 records 0.0 20.0 0.0 0.0 5.0 7.0 29.6
Filtering is *usually* done by iterating the data. Now some engines use server
side iteration, some even use indexes for it, but other engines use client
side filtering. Each has it benefits and disadvantages in terms of speed and
what you can do with it. Since there's no specs in the VCL which type of
filtering an engine should do, it's a bit of a gray area that you need to look
at with utter care. Some engine allow to use some or all of above modes
depending on which one you want.
You also mention that you're using Exclusive mode. Again engines treat that
different or have different modes for it. Generally spoken the exclusive tag
is kind of putting the use of a database ad absurdum as for almost db engines
I know, concurrent data access is one of the main design points.
Don't get me wrong, I don't want to bad mouth your effort on this, but I just
want to make you aware that the testing can be very misleading and real world
(real data) experiences can be in extreme case the exact opposite of what you
see in streamlined benches.
--
Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm
Ian Roberts
that most of them have negligible effects on speed (except transactions,
that I have used when available). Many of those settings do not seem to have
have important effects on the performance and I decided to use the default
ones. However, a couple of vendors did suggest some changes in TTable or
TDatabase settings, and I implemented them, but I didn't saw any noticable
effect on the speed of the various tasks. If some vendors think I should
change some of the default settings, they are free to ask me.
A limited benchmark is better than no benchmark at all, and I did it
initially to test typical tasks in my own application. I will leave to
people the decision as to whether this benchmark is useful or whether some
of those results are relevant or not.
Ian
"Hannes Danzl[NDD]" <han...@nexusdb.dbnexus.com> wrote in message
news:xn0f1jw7l...@newsgroups.borland.com...
Hannes Danzl[NDD]
> have important effects on the performance and I decided to use the default
> ones. However, a couple of vendors did suggest some changes in TTable or
> TDatabase settings, and I implemented them, but I didn't saw any noticable
> effect on the speed of the various tasks. If some vendors think I should
> change some of the default settings, they are free to ask me.
Look here for an example of what some simple changes can do to performance:
http://www.nexusdb.com/new/index.php?q=node/237
> A limited benchmark is better than no benchmark at all, and I did it
> initially to test typical tasks in my own application.
That's exactly the point. This is your benchmark and it is sufficient for your
purposes. As said, don't get me wrong, nothing wrong with, but our sales team
has been hit with a flood of questions before when we left public benches
regarding database engine uncommented. People unfortunately often draw the
conlcusion that if a benchmark shows that dbenginex is best suited for
testery, then it's the same for themselves even though they have a complete
different spec.
Ian Roberts
"NexusDB has a very fast engine structure at its heart and performs
very well out of the box"
I offered to people from NexusDB the possibility to test this using the same
code as the other engines, so I asked them to provide me a close translation
of the routines I have used. If the NexusDB engine already performs quite
well "out of the box", then why are they reluctant to participate to such a
test?
And if vendors wish to show how fast their engine can be on those same task
but with specific features (batch move, transaction, etc.), they may also
send me an example of an optimized routine using all available tricks in
their engine. I could then create a second table using codes optimized by
vendors.
Ian
Hannes Danzl[NDD]
> This page mention:
>
> "NexusDB has a very fast engine structure at its heart and performs very
> well out of the box"
>
> I offered to people from NexusDB the possibility to test this using the same
> code as the other engines, so I asked them to provide me a close translation
> of the routines I have used. If the NexusDB engine already performs quite
> well "out of the box", then why are they reluctant to participate to such a
> test?
We only got the request per mail yesterday, we've just released a new version
and thus didn't have time so far to attend to it. And yes we are reluctant for
the reasons mentioned above: people have misinterpreted benchmark results
(even if they were in our favour) and will do it again. A benchmark is only
good if the test procedures match the environment they are created for,
otherwise they are generally of no big use except showing that in bench a
database a wins or in bench b database b wins.
Ian Roberts
Thursday asking some questions about the benchmark (I answered the same
day). He sent me another message the next day, asking other questions. If
you got this message only yesterday, then I am not the one responsible for
this.
Several NexusDB users were curious to know how NexusDB would fare in such a
benchmark, so I guess I will have to wait for someone else to volunteed to
make the few required changed to test NexusDB or spend the time myself
trying to learn how it work.
Here is a simplified version of the routines I asked people from NexusDB to
adapt (with the fewest changes as possible, except for start transaction and
commit). I guess this translation would take only a few minutes since the
main problem I have is with the creating of the database and table (the
first few lines).
Ian
procedure TForm1.Button1Click(Sender: TObject);
var
I: Integer;
S: string;
R: Double;
begin
DB.Close;
Randomize;
DB.CreateDatabase;
if Table1.Exists then Table1.DeleteTable;
Table1.FieldDefs.Clear;
Table1.FieldDefs.Add('IdName', ftInteger, 0, False);
Table1.FieldDefs.Add('name', ftString, 20, False);
Table1.FieldDefs.Add('RandomN', ftFloat, 0, False);
Table1.CreateTable;
Table1.Open;
for I := 1 to 1000000 do begin
Table1.Append;
Table1.FieldByName('IdName').AsInteger := I;
Table1.FieldByName('name').AsString := 'John '+IntTostr(Random(1000));
Table1.FieldByName('RandomN').AsFloat := Random * 1000;
Table1.Post;
end;
Table1.First;
repeat
R := Table1.FieldByName('RandomN').AsFloat;
S := Table1.FieldByName('name').AsString;
Table1.Next;
until Table1.Eof;
Table1.First;
repeat
Table1.Edit;
Table1.FieldByName('RandomN').AsFloat :=
Table1.FieldByName('RandomN').AsFloat;
Table1.FieldByName('name').AsString :=
Table1.FieldByName('name').AsString;
Table1.Next;
until Table1.Eof;
For I := 1 to 50 do begin
J := StrToInt(RandomList[i]);
Table1.Locate('IdName',J,[]);
end;
Table1.Close;
Table1.RestructureIndexDefs.Add('First', 'Idname', [], false, 'name',
'name');
Table1.RestructureTable;
Table1.Open;
Table1.Filtered := False;
Table1.Filter := 'RandomN < 100';
Table1.Filtered := True;
Table1.Filtered := False;
Table1.Close;
DB.Close;
end;
"Hannes Danzl[NDD]" <han...@nexusdb.dbnexus.com> wrote in message
news:xn0f1jz3r...@newsgroups.borland.com...
Hannes Danzl [NDD]
> to
> adapt (with the fewest changes as possible, except for start transaction
> and
> commit). I guess this translation would take only a few minutes since the
> main problem I have is with the creating of the database and table (the
> first few lines).
Here's the NexusDB version.
uses
nxdb, nxsrServerEngine, nxseAllEngines
var
ServerEngine: TnxServerEngine;
Session: TnxSession;
Database: TnxDatabase;
Table1: TnxTable;
begin
ServerEngine:=TnxServerEngine.Create(self);
Session:=TnxSession.Create(self);
Database:=TnxDatabase.Create(self);
Table1:=TnxTable.Create(self);
Session.ServerEngine:=ServerEngine;
Session.Open;
Database.Session:=Session;
Database.AliasPath:=extractfilepath(paramstr(0));
Table1.Database:=Database;
Table1.TableName:='Test';
if Table1.Exists then
Table1.DeleteTable;
Table1.FieldDefs.Clear;
Table1.FieldDefs.Add('IdName', ftInteger, 0, False);
Table1.FieldDefs.Add('name', ftString, 20, False);
Table1.FieldDefs.Add('RandomN', ftFloat, 0, False);
Table1.CreateTable;
Table1.Open;
Database.StartTransaction; // use of transaction in NexusDB is vital
// otherwise every single post gets physically to disk by forcing
// the OS to flush
try
for I := 1 to 1000000 do begin
Table1.Append;
Table1.FieldByName('IdName').AsInteger := I;
Table1.FieldByName('name').AsString := 'John '+IntTostr(Random(1000));
Table1.FieldByName('RandomN').AsFloat := Random * 1000;
Table1.Post;
end;
Database.Commit;
except
Database.Rollback;
raise;
end;
Table1.First;
repeat
R := Table1.FieldByName('RandomN').AsFloat;
S := Table1.FieldByName('name').AsString;
Table1.Next;
until Table1.Eof;
Table1.First;
Database.StartTransaction;
try
repeat
Table1.Edit;
Table1.FieldByName('RandomN').AsFloat :=
Table1.FieldByName('RandomN').AsFloat;
Table1.FieldByName('name').AsString :=
Table1.FieldByName('name').AsString;
Table1.Post;
Table1.Next;
until Table1.Eof;
Database.Commit;
except
Database.Rollback;
raise;
end;
Table1.Close;
Table1.AddIndex('First', 'IdName', []);
Table1.Open;
For I := 1 to 50 do begin
J := randomlist[i];
Table1.Locate('IdName',J,[]);
end;
Table1.Filtered := False;
Table1.Filter := 'RandomN < 100';
Table1.Filtered := True;
Table1.Filtered := False;
Table1.Close;
kh.af...@gmail.com
Both Firebird 1.5 & 2 since the latter has optimized more.
Thanks in advance
Ian Roberts
performances for those tasks. More soon!
"Hannes Danzl [NDD]" <han...@nexusdb.dbnexus.com> wrote in message
news:45b57f05$1...@newsgroups.borland.com...
Martijn Tonies
> Both Firebird 1.5 & 2 since the latter has optimized more.
There's no point really.
He is using TTable-like database systems, which are very very
different from SQL based systems.
There's lies, damned lies and benchmarks.
:-)
--
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com
Ian Roberts
Result table. Best viewed with courrier
ABS EASY ALS DISQ DBISAM TURBO ACC NEXT
Single file Yes Yes No Yes No Yes Yes Yes
Standard TTable commands Yes Yes Yes No Yes Yes Yes YES
Without Index (EXLCUSIVE = TRUE)
Creating records 53.1 810.0 93.3 6.1 128.9 31.5 78.9 25.4
Reading all data 6.0 181.0 8.0 1.6 4.7 6.4 37.0 7.3
Rewriting records 27.4 593.8 57.8 4.6 74.1 61.4 65.4 32.2
Locate (50 times) 68.3 713.2 17.2 11.5 257.1 179.8 57.7 8.2
Create index 178.4 1141.3 1.0 6.4 7.5 9.1 257.8 8.5
Reading all data 10.2 256.6 17.3 3.4 5.7 6.1 77.4 7.2
Rewriting records 129.2 764.2 60.9 6.5 73.8 49.3 105.7 63.3
Locate (5000 times) 0.8 3.5 0.3 0.1 0.5 1.4 1.0 0.1
Filter 1 of 10 records 0.0 20.0 0.0 0.0 5.2 8.6 21.1 0.0
EXE increase 808K 577K 119K 304K 994K 1027K 969K 737K
DLL size - - 2113K - - - - -
Size of TEST DB (+index) 89MB 140MB 55MB 41MB 103MB 48MB 105Mb 81MB
kh.af...@gmail.com
Martijn Tonies wrote:
> > Ian, would you please add Firebird to your benchmark?
> > Both Firebird 1.5 & 2 since the latter has optimized more.
>
> There's no point really.
>
> He is using TTable-like database systems, which are very very
> different from SQL based systems.
>
> There's lies, damned lies and benchmarks.
>
> :-)
Hey Martin! Nice job with DB Workbench! My favorite of all!
I know. But benchmarks have their own use.
For example, now I know that if I'm going to make a simple Database -
for example a huge Telephone book CD - I'm going for DISQLite. The
benchmark has really shown it's a good choice for those kind of usage.
Many have noticed the performance, I'm noticing DB file size ;) It has
nothing with connection technology, components, disk fragmentation,
....
Accuracer sucked in this benchmark, it sucked when I gave it a test
myself, so there must be some point for the eye of the wise.
I'd like to see how Firebird performs in this particular kind of
Benchmark.
There are Benchmark results, Benchmark_S_ Results, Statistics, and
conclusions!
Liz
> DISQL
Curious, I did a quick search but didnt turn up a home page..
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
brekhof
>
>> DISQL
>
>Curious, I did a quick search but didnt turn up a home page..
http://www.fredshack.com/docs/sqlite.html
--- posted by geoForum on http://delphi.newswhat.com
John Herbster
"Liz" <liz_want...@xcalibur.nospam.co.uk> wrote
>> DISQL
> Curious, I did a quick search but didnt turn up a home page..
Maybe a typo in original post of this thread made a little
confusing.
I think that this is it:
http://www.zeitungsjunge.de/delphi/sqlite3/
Regards, JohnH
Liz
> > Curious, I did a quick search but didnt turn up a home page..
>
> http://www.fredshack.com/docs/sqlite.html
Hmm, perhaps a title of sqlite instead of disql would have been more
sensible :)
Liz
> Maybe a typo in original post of this thread made a little confusing.
> I think that this is it: http://www.zeitungsjunge.de/delphi/sqlite3/
> Regards, JohnH
Well that explains a little as to why DISQL doesnt return anything, its
called SQLite!
Uffe Kousgaard
news:xn0f1k8q1...@newsgroups.borland.com...
>
> Hmm, perhaps a title of sqlite instead of disql would have been more
> sensible :)
Unless it is this one:
http://www.zeitungsjunge.de/delphi/sqlite3/
They use the name DISQLite3
Hannes Danzl[NDD]
> I have started doing the tests and NexusDB seems to show very good
> performances for those tasks. More soon!
Thanks Ian.
--
Hannes Danzl [NexusDB Developer]
Hannes Danzl[NDD]
> Here are the latest results with NexusDB and a correction:
Sweet :)
Thanks!
Jerry Hayes
Just a few notes about NexusDB and the benchmarks:
NexusDB supports both native Guids (binary) and VarChar columns. One of the
few, if not only, one in the list that does so.
That could have a *major* factor on database sizes.
Hannes Danzl[NDD]
> > > Here are the latest results with NexusDB and a correction:
>
> Just a few notes about NexusDB and the benchmarks:
>
> NexusDB supports both native Guids (binary) and VarChar columns. One of the
> few, if not only, one in the list that does so.
>
> That could have a major factor on database sizes.
Sure can have. NexusDB also supports an optional variable record size (which
is not used in this benchmark) which can reduce stored size significantly.
With the default static record engine all records are the same size on disk
and whether you use varchar() or char() won't make a difference size wise. The
only difference is that (conforming to the SQL standard) char() fields are
returned padded with spaces to the defined length.
Ralf Junker - http://www.yunqa.de/delphi/
>> DISQL
>
>Curious, I did a quick search but didnt turn up a home page..
"DISQL" means DISQLite3, as Ian has stated near the very bottom in his initial
message to this thread.
The DISQLite3 home page is at http://www.yunqa.de/delphi/sqlite3/.
Please notice that Ian's "DISQL" results apply to DISQLite3 specifically, not to
just any SQLite implementation for Delphi.
DISQLite3 binds more closely with Delphi and uses register calling conventions
throughout, which results in noticeable performance improvements.
Users of my SQLiteSpy database manager - which deploys DISQLite3 - reported this
difference after they experienced that SQLiteSpy performed way faster than their
own application using the original SQLite.
Ralf
---
The Delphi Inspiration
http://www.yunqa.de/delphi/
Ralf Junker - http://www.yunqa.de/delphi/
>NexusDB supports both native Guids (binary) and VarChar columns. One of the
>few, if not only, one in the list that does so.
In DISQLite3, text columns are ALWAYS variable length (up to 2 gibibytes)
without any performance penalty. In fact, DISQLite3 uses variable length record
throughout, even for integers.
This has a number of advantages: It obviously results in smaller database files.
But it also makes the database run faster, since there is less information to
move to and from disk.
For example, if you store a single character in a VARCHAR(100) column, then only
a single byte of disk space is consumed. (Actually two bytes - there is some
overhead at the beginning of each column to record its datatype and length.)
>That could have a *major* factor on database sizes.
For DISQLite3, it definitely is!
Martijn Tonies
> > > Both Firebird 1.5 & 2 since the latter has optimized more.
> >
> > There's no point really.
> >
> > He is using TTable-like database systems, which are very very
> > different from SQL based systems.
> >
> > There's lies, damned lies and benchmarks.
> >
> > :-)
>
> Hey Martin! Nice job with DB Workbench! My favorite of all!
Thanks :-)
> I know. But benchmarks have their own use.
> For example, now I know that if I'm going to make a simple Database -
> for example a huge Telephone book CD - I'm going for DISQLite. The
> benchmark has really shown it's a good choice for those kind of usage.
As others have mentioned, yes, they are usuable for you.
> Many have noticed the performance, I'm noticing DB file size ;) It has
> nothing with connection technology, components, disk fragmentation,
> ....
>
> Accuracer sucked in this benchmark, it sucked when I gave it a test
> myself, so there must be some point for the eye of the wise.
>
> I'd like to see how Firebird performs in this particular kind of
> Benchmark.
>
> There are Benchmark results, Benchmark_S_ Results, Statistics, and
> conclusions!
Different database systems have different requirements, this will affect
the benchmarks as well. For example, it could very well be that Firebird
is slowish at your benchmark, but faster if the routines are ran multiple
times at the same time.
Dave Keighan
> I completed a more comprehensive benchark of various database engines
> (adding a Locate procedure and two new database engines, TurboDB and
> Accuracer). I also increased the number of records to 1 million in
> order to achive better accuracy. I believe some people would be
> interested in seeing my results. I will likely add NexusDB to this
> table later this week.
> ABS - ABSOLUTE DATABASE v5.11
Based on your results and a number of personal items, Single file =
TRUE being one of them, price another, ease of use ... I decided to
give ABS a run for its money. It's taken a while, but I've kludged
things together to get it installed with Instant Objects and have been
running trials on it using the Primer Demo that comes as an example
with the IO files. I was wondering if you could/would add an MS Access
DB through ADO to your tests? To be frank, it's beating the crap out
of ADS in the primitive testing that I'm doing. Additionally as a long
time Access user [I have a dark VB history] I'd like to see how it
holds up against the [supposed] big guys.
Anything I could do to help [an MT MDB file perhaps] I would be most
happy to,
--
Dave
Shop Steward Local 55129
Union of Delphi Hobbyists and Occupational Developers