Re: Robust Single File database - updated benchmark results

I am aware of the effect of all those settings, although my experience is
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]" <hannes@xxxxxxxxxxxxxxxxxxx> wrote in message
news:xn0f1jw7lim83n4004@xxxxxxxxxxxxxxxxxxxxxxxxx
I've no idea how NX performs as i've not seen any source or data for that.

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


.

Relevant Pages

  • Re: Activesync replacement?
    ... Look through the AS settings on the device, ... If you don't like the engine in your Honda, ... ActiveSync is configured to use it. ... Exchange, it doesn't force Exchange to magically appear on your network, ...
    (microsoft.public.pocketpc.activesync)
  • Re: And after the trip...
    ... Brand new engine to boot. ... I have gotten pretty good with our new Tom Tom.. ... settings and missed the volume button on the page before going to settings, ... them and he automatically recalculated route. ...
    (rec.boats)
  • Re: Power setting table and best economy/best power...
    ... >"best economy" power settings is fuel flow and engine temperature. ...
    (rec.aviation.piloting)
  • Re: If you are thinking of buying a BMW read this
    ... traction control settings using the i-Drive... ... Not sure why you would need 3 engine power ... combinations of programmable setups for the car. ... can even shift itself like an automatic. ...
    (alt.autos.bmw)
  • Re: Robust Single File database - updated benchmark results
    ... This is heavily depending on several things: ... Every database has it's own default settings that are not necessarily (or in ... always need to understand the settings of a db engine and use them to your ... side iteration, some even use indexes for it, but other engines use client ...
    (borland.public.delphi.thirdpartytools.general)